リリースブランチを持つことのリスクは何ですか？
現在、Microsoft Team Foundation Serverプロジェクトでソースコードを管理しています。次のブランチがあります。
- 開発
- 特徴1
- 特集2
- 等。
- テスト
プロセスは、開発が開発で行われるか、別の機能ブランチで行われることです。機能と修正が完了すると、それらはTestブランチにマージされ、テスト環境に展開されます。 Testブランチの受け入れテストが成功したら、テストビルドからリリースを作成し、本番環境にデプロイします。
このアプローチの理由は、テストされたものとは異なるコードをデプロイするため、本番環境にビルドしてデプロイする前に、TestからReleaseブランチへのマージを行いたくないためです。
このアプローチの欠点は、テストブランチで待機しているテストされていない変更がしばしばあり、本番環境での重大なバグのホットフィックスの配信が遅れることです。
業界ではリリースブランチにマージしてから展開するのが一般的だと思います。個別のリリースブランチがある場合に、簡単なホットフィックスを可能にし、テストされていない違いのリスクを導入しない方法はありますか？
...多くの場合、テストブランチで待機している未テストの変更があり、本番環境の重大なバグのホットフィックスの配信を遅らせます。
個別のリリースブランチがある場合に、簡単なホットフィックスを可能にし、テストされていない違いのリスクを導入しない方法はありますか？
はいあります。発生した問題は、ワークフローのバグが原因です。
feature1 \
feature2 --> test --> release
hotfix1 /
ご覧のように、機能を徹底的にテストするのに時間がかかる場合、それらはパイプラインを介してホットフィックスを取得するためのバリアとして機能します。ここで重要なのは、リリースを迅速に入手する必要がある場合、リリースパイプラインには準備が整っていないものがあってはならないということです。
変更をテストする際の遅延が変更に留まるように、バリアをパイプラインのリリース部分の前に移動することでそれを防ぐことができます。
feature1 --> feature1-test \
feature2 --> feature2-test --> release-test --> release
hotfix1 --> hotfix1-test /
変更が完了すると、別のブランチに移動してテストされます。テストが進行している限り、その変更に関するすべての作業は2つのブランチ間で行われます。テストがそれを承認した後、テストされたコードはリリース前のテストブランチにマージされ、リリース前にフルテストバッテリーがもう一度実行されます。 （理論的には、これは形式的でイベントではないはずです。理由は後で説明します。）これは、feature1またはhotfixを遅らせることなく、feature2をテストするのに時間がかかることを意味します。
見落とされがちな重要なことの1つはフィードバックです。リリースが発生するたびに、そのコードは、開発とテストが行われているすべてのブランチにマージされる必要があります。 hotfix1がfeature1に違反する場合は、feature1-testでそれを見つけて修正し、hotfix2を含むリリースの邪魔にならないようにする必要があります。機能がリリースされた変更を早期に統合する場合、release-testでの驚きは少なくなります。この配置により、開発の観点からホットフィックスと機能を同じように扱うことができ、ホットフィックスをテストのフルバッテリーに適用するか、それともQAポリシーの問題で高速追跡するかを決定します。ワークフローは何があっても同じであり、releaseブランチへの簡単なブランチ/マージはありません。
注意：ここで説明するのは、feature1の何かが考慮されず、feature2の何かが壊れているため、少し単純化しすぎています。この配置は、release-testがintegration-testになり、release-testを供給する、より複雑な構造で使用できます。
あなたのような環境では、分岐戦略を使用して、リリースブランチのホットフィックスブランチで本番ホットフィックスを実行する必要があります。テストして承認したら、これらの変更を上流の開発ブランチとテストブランチにマージする必要があります。これは非常に保守的な分岐戦略です。そして、追加のマージは、リリースでそのレベルの安全性を確保するためのトレードオフの1つです。
あなたの問題の根本的な原因は機能ブランチの使用です（私自身も含め、一部の人々はそれらを「悪」だと考えています）。単一のリリースブランチを取得するためにそれらをマージすることはボトルネックです。ブランチマージは、回避できない品質レベルの不連続点であり、不明な量の作業/リソースを必要とし、シリアル化する必要があり、適切に計画できないなどの原因となります。ホットフィックスとリリースブランチの間の障害となる、テストされていない/進行中の機能バックログ。
あるブランチで適切に機能する変更が別のブランチで同じように（またはまったく）機能することが保証されていないことを人々はしばしば忘れます。機能全体が独自の開発ブランチで問題なく機能し、リリースする必要のある他のすべての機能とマージされたときに完全に台無しにされます。また、問題を引き起こしている個々の変更を特定することもできません。オールオアナッシングアプローチをとる必要があります。マージをキャンセルする（つまり、ブランチの変更を統合しない）か、マージを受け入れます（すべてを含む）その変更）、潜在的な容疑者を常に意識することなく、対処する必要がある品質レベルでヒットを取得します。
継続的インテグレーションアプローチでは、マージする機能ブランチはありません-バックログやそのような障害はありません。すべての変更は小さく保たれ、修正プログラムや新機能の一部であるかどうかに関係なく、いつでもsingleブランチに入ることができます。欠陥のあるものはすぐに識別されて対処され、自動化は非常に役立ちます（そうです、CIには常にvery shortがありますが、疑わしいリストが空になることはありません）。品質レベルの不連続点はなく、品質は常に測定/監視されており、ツールを使用して自動的に実施することもできます。
単一のメイン/マスターブランチを実際のリリース手段として実際に使用できず、リリースブランチが必要な場合でも（たとえば、組み込みソフトウェアやOS開発の場合など、継続的な展開がオプションでない場合は完全に正常です）、引き続き使用できます。リリースブランチレベルでの継続的な統合。つまり、neverリリースブランチをリベース/親に変更するか、他の機能/統合ブランチにマージして、（他のブランチのコンテキストで）正常に動作しているように見える一連の変更を取り込みます。
リリースブランチ用に開発された、または他のブランチから移植/ダブルコミットされた「最新機能」開発の各変更、修正プログラム、または一部でさえ、受信側のリリースブランチの特定のコンテキストに適用される同じチェックを通過します。これにより、最終的にそのリリースの最低品質レベルが保証されます。これが、CI/CDがソフトウェアを確実にリリースする最速の方法であると私が信じる理由です。
一般に、この問題を処理するために実行できる2つのバージョン管理アプローチがあります。
1. GitFlow
ここには、機能ブランチが長く存続していて、それらが完了すると開発ブランチにマージされます。次のリリースのすべての機能が完了すると、開発ブランチはマスターブランチにマージされます。ホットフィックスを適用する必要がある場合、マスターブランチから新しいブランチが作成され、その新しいブランチでホットフィックスがコミットされ、そのブランチがマスターにマージされて開発されます（その後、マスターブランチをテスト環境にデプロイし、そのバージョンをテストし、その後、より高い環境に展開します）。
開発にしばらく時間がかかった機能ブランチでは、多くのマージ競合が発生する可能性があります。これは、開発ブランチの機能ブランチを頻繁にリベースすることによって（または、開発ブランチを機能ブランチにマージすることによって）軽減できます。
2. TrunkBased開発
トランクベースの開発では、長く生きているブランチはなく、マスターブランチしかありません。したがって、各コミットはmasterブランチにあり、すべての環境にすぐにデプロイされます。機能フラグは、以前の環境でテストされていない場合、変更が本番環境で表示されないようにするものです。このようにして、マージの競合を解決するためのハードワークはありません。ただし、代わりに機能フラグを管理するオーバーヘッドが発生します。