Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
Team Foundation バージョン管理 (TFVC) リポジトリのブランチを作成することは、リスクを分離するのに役立ちます。 チーム メンバーが 5 人以上または 10 人を超えるスタッフを配置するソフトウェア プロジェクトに取り組むときに、通常直面する課題をいくつか考えてみましょう。
グループには複数の異なる機能チームがあり、それぞれが合理的に個別の機能のセットに取り組んでいます。 ただし、各チームは、他のチームによって構築された機能にも依存します。 これらの各チームで行われた作業によって導入された変更のリスクを分離する必要があり、最終的には、すべての作業を 1 つの製品にマージする必要があります。
テスト チームは、テストするために安定したバージョンのコードを必要としますが、同時に、開発者は製品を不安定化させる新機能を引き続き進める必要があります。
ソフトウェアには、2 つの以前のバージョンと 1 つの現在のバージョンが進行中です。 開発作業のほとんどは現在のバージョンに投資されていますが、以前のバージョンは、サービス パック、重要な修正プログラム、セキュリティ パッチ、およびその他の変更の不定期リリースで引き続きサポートされる必要があります。
この記事では、適切な決定を下すのに役立ついくつかの一般的な分岐戦略について説明します。
リポジトリ スコープの Git ブランチとは異なり、TFVC ブランチはパス スコープであり、軽量ではありません。 コードまたはリリースの分離が必要な場合は、分岐を高くし、ブランチのみを作成するためのバーを設定します。
メインのみ
メインのみの戦略は、フォルダー ベースにすることも、メイン フォルダーをブランチに変換して、さらに表示機能を有効にすることもできます。 メイン ブランチに変更をコミットし、必要に応じて、開発マイルストーンとリリース マイルストーンをラベルで示します。
リスク: TFVC ラベルの変更可能性と履歴の欠如により、変更制御のリスクが生じます。
主要な唯一の分岐戦略から始め、 戦略的に分岐 し、必要に応じてより複雑な戦略に進化するための他の戦略を採用します。
開発の分離
安定したメイン ブランチを維持して保護する必要がある場合は、メインから 1 つ以上の開発ブランチをブランチできます。 分離と同時開発が可能になります。 機能、組織、または一時的なコラボレーションによって、開発ブランチで作業を分離できます。
メイン ブランチに変更がある可能性があります。 常にメインの統合 (FI) を開発ブランチに転送し、マージの競合を解決します。 次に、逆統合 (RI) が メインに戻ります。 ブランチ間で同じ品質バーを維持します。 メインで行うのと同じ方法で 、開発 時にビルド検証テスト (BFT) をビルドして実行 します。
注: この戦略では、チームは 開発 ブランチを永遠に維持し、大規模なマージ チケット履歴を構築する可能性があります。
機能の分離
機能の分離は、開発分離の特別な派生物であり、1 つ以上の 機能 ブランチを メインブランチから、または 開発 ブランチからブランチすることができます。
特定の機能で作業する必要がある場合は、機能ブランチを作成することをお勧めします。
機能作業と関連する機能ブランチの有効期間を短くします。 親ブランチからの前方統合 (FI) の変更が頻繁に行われます。 逆統合 (RI) は、一部の合意されたチーム条件 (例: done の定義) が満たされている場合にのみ、親に戻ります。 メインの機能のロールバックはコストがかかり、テストがリセットされる可能性があります。
リリースの分離
リリース分離では、メインから 1 つ以上のリリース ブランチが導入されます。 この戦略により、同時リリース管理、複数および並列リリース、およびリリース時のコードベース スナップショットが可能になります。
リリースをロックダウンする準備ができたら、リリース用の新しいブランチを作成します。
メインから統合 (FI) を転送しないでください。 アクセス許可を使用してリリース ブランチをロックし、 リリースに対する意図しない変更を防ぎます。 リリース ブランチに対して行われた修正プログラムとホットフィックスは、メイン ブランチに逆統合 (RI) できます。
注: どの分岐シナリオも不変ではないので、リリース ブランチで緊急修正プログラムが実行されていることがわかります。 複雑さと関連コストを見失うことなく、要件に合わせて各戦略を進化させます。
サービスとリリースの分離
サービスとリリースの分離戦略では、 サービス ブランチが 導入されます。 この戦略により、リリース時にサービス パックとコードベース スナップショットの同時サービス管理が可能になります。
この戦略は、お客様が次のメジャー リリースにアップグレードし、リリースごとに追加のサービス パックにアップグレードするためのサービス モデルが必要な場合に使用します。
リリース分離と同様に、 サービス分離 と リリース ブランチは、リリースをロックダウンする準備ができたときに作成されます。 メインからサービス、またはサービスからリリースに統合を転送しないでください。 変更を防ぐために リリース ブランチをロックします。 今後のサービスの変更は、 サービス ブランチで行うことができます。
そのレベルの分離が必要な場合は、後続のリリース用に新しいサービス ブランチとリリース ブランチを作成します。
サービス、修正プログラム、リリースの分離
推奨されませんが、追加の 修正プログラム ブランチと関連するリリース シナリオを導入することで、戦略を進化させ続けることができます。
この時点で、TFVC 分岐の一般的なシナリオをいくつか確認できました。 それらを進化させたり、 機能の切り替え、機能のオンとオフの切り替えなどの他の戦略を調査して、実行時に機能を使用できるかどうかを判断したりできます。
Q&A
ブランチの有効期間が短い必要がある理由
ブランチの有効期間を短くすることで、マージの競合は可能な限り少なくなります。
必要に応じて分岐する理由
DevOps を採用するには、ビルド、テスト、デプロイの自動化に依存する必要があります。 マージの競合には手動による介入が必要になることが多いため、変更は 継続的で頻繁で、マージ操作はより困難になります。 そのため、分岐を回避し、機能の切り替えなどの他の戦略に依存することをお勧めします。
ブランチを削除する理由
目標は、長期的なマージの結果を軽減するために、できるだけ早く変更を メイン に戻す必要があります。 一時的なブランチ、未使用のブランチ、豊富なブランチは、チームの混乱とオーバーヘッドを引き起こします。
コードベースはプロジェクト間で分岐できますか?
Yes. チームがソースを共有する必要があり、共通のプロセスを共有できない場合を除き、これはお勧めしません。
コードプロモーション戦略はどうですか?
コードプロモーション戦略は、滝の開発時代の遺跡のように感じます。 通常、テスト サイクルが長く、開発チームとテスト チームが分かれています。 戦略は推奨されなくなりました。 この戦略の詳細については、 分岐ガイダンスを参照してください。
開発をメイン ブランチにマージする場合、変更が検出されないのはなぜですか?
たとえば、 keep source 競合解決オプションを使用するなど、以前のマージの変更は無視されている可能性があります。 詳細については、「 開発ブランチをメインにマージする」を参照してください。マージする変更はありませんでした 。
TFVC と Git ブランチ戦略の間に類似点はありますか?
TFVC 機能分離分岐戦略は、Git トピック ブランチに似ています。
著者: ALM の Jesse Houwing、マークス・フェルナンデス、マイク・フーリー、ウィリー・シャウブ |DevOps Rangers。 お問い合わせはこちら
(c) 2015 Microsoft Corporation。 All rights reserved. このドキュメントは"as-is." で提供されています。URL やその他のインターネット Web サイトの参照を含め、このドキュメントに記載されている情報およびビューは、予告なしに変更される場合があります。 使用するリスクを負います。
このドキュメントは、Microsoft 製品の知的財産権に関する法的な権利をお客様に許諾するものではありません。 内部での参照を目的とする場合、このドキュメントをコピーして使用できます。