効率的な分岐戦略を選択する

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Team Foundation バージョン管理 (TFVC) リポジトリのブランチを作成すると、リスクを分離するのに役立ちます。 5 人から 10 人を超えるスタッフがいるソフトウェア プロジェクトで作業する場合、チーム メンバーが一般的に直面する複数の課題について検討します。

  • グループには数個 (またはもっと多く) のさまざまな機能チームがあり、適切に分けられた一連の機能にそれぞれが取り組んでいます。 また、各チームは他のチームがビルトする機能にも依存しています。 こうした各チームで実行された作業によってもたらされる変更のリスクを分離する必要があります。さらに最終的には、すべての作業を 1 つの製品にマージする必要があります。

  • テスト チームには、テスト対象として安定したバージョンのコードが必要ですが、同時に、開発者の方では新機能の開発を続ける必要があります。こうした新機能によって製品が不安定になることもよくあります。

  • このソフトウェアには、以前のバージョンが 2 つと、進行中の最新バージョンが 1 つあります。 ほとんどの開発リソースを最新バージョンの方に割り当てている場合であっても、以前のバージョンをサポートすることが必要になり、場合によってはサービス パック、重要な修正、セキュリティ パッチなどの変更をリリースする必要が生じることもあります。

この記事では、適切な決定を行うために役立ついくつかの一般的な分岐戦略について説明します。

リポジトリ スコープ付きの Git ブランチとは異なり、TFVC ブランチはパス スコープ付きであり、軽量ではありません。 ブランチを作成するハードルを高く設定し、コードやリリースを分離する必要がある場合にのみブランチを作成します。

メインのみ

メインのみ戦略は、フォルダーベースまたはメイン フォルダーをブランチに変換することで、追加の可視性機能を有効にすることができます。 メイン ブランチに変更をコミットし、必要に応じてラベルを用いて開発およびリリースのマイルストーンを示します。

メインのみの分岐戦略

リスク: TFVC ラベルを使用した変更可能性と履歴の欠如により、変更制御のリスクが高まる可能性があります。

メインのみの分岐戦略から始め、戦略的に分岐し、他の戦略を採用して、必要に応じてより複雑な戦略に進化させます。

開発の分離

安定したメイン ブランチを維持して保護する必要がある場合は、メインから複数の開発ブランチを分岐することができます。 そうすることにより、分離と同時開発が可能になります。 作業は、機能、組織、または一時的なコラボレーションによって開発ブランチで分離できます。

開発者分離の分岐戦略

メイン ブランチに変更がある可能性があります。 常にメインを開発ブランチに順方向に統合 (FI) し、マージの競合を解決します。 その後、変更をメインに逆方向に統合 (RI) し直します。 ブランチ間で同じ品質レベルを維持します。 メインで行うのと同じ方法で、開発でビルドして、ビルド確認テスト (BVT) を実行します。

注: この戦略では、チームは開発ブランチを永遠に維持することになり、大規模なマージ チケット履歴をビルドする可能性があります。

機能分離

機能分離は、開発分離が特別に派生したものであり、図のように、メイン ブランチ、または開発ブランチから 1 つ以上の機能ブランチを分岐できます。

機能分離の分岐戦略

特定の機能に取り組む必要がある場合は、機能ブランチを作成することをお勧めします。

機能に関する作業と関連する機能ブランチの有効期間を短く保ちます。 変更は、親ブランチから頻繁に順方向に統合 (FI) されます。 完了の定義など、一部の合意されたチーム条件が満たされている場合にのみ、親に逆方向に統合 (RI) されます。 メインの機能のロールバックにはコストがかかる可能性があり、テストがリセットされることがあります。

リリース分離

リリース分離では、メインから 1 つ以上のリリース ブランチが導入されます。 この戦略により、同時リリース管理、複数および並列リリース、およびリリース時のコードベース スナップショットが可能になります。

リリース分離の分岐戦略

リリースをロックダウンする準備ができたら、リリース用の新しいブランチを作成します。

メインから順方向に統合 (FI) しないでください。 リリースへの意図しない変更を防ぐために、アクセス許可を使用してリリース ブランチをロックします。 リリース ブランチに対して行われたパッチと修正プログラムは、メイン ブランチに逆向きに統合 (RI) できます。

注: どの分岐シナリオも不変ではないため、リリース ブランチで緊急修正プログラムが実行されていることがわかります。 複雑さと関連コストを見落とすことなく、それぞれの戦略をご自身の要件に合わせて進化させてください。

サービスとリリース分離

サービスとリリース分離戦略では、サービス ブランチが導入されます。 この戦略により、Service Pack の同時サービス管理、およびリリース時のコードベース スナップショットが可能になります。

サービス リリース分離の分岐戦略

この戦略は、お客様が次のメジャー リリースにアップグレードするためのサービス モデルと、リリースごとの追加の Service Pack が必要な場合に使用します。

リリース分離と同様に、サービス分離ブランチとリリース ブランチは、リリースをロックダウンする準備ができたときに作成されます。 メインからサービスに、またはサービスからリリースに順方向に統合しないでください。 変更を防ぐために、リリース ブランチをロックします。 今後のサービス変更は、サービス ブランチで行うことができます。

そのレベルの分離が必要な場合は、後続のリリース用に新しいサービス ブランチとリリース ブランチを作成します。

サービス、修正プログラム、リリース分離

推奨されませんが、追加の修正プログラム ブランチと関連するリリース シナリオを導入することで、戦略を引き続き進化させることができます。

サービス修正プログラム リリース分離の分岐戦略

この時点で、いくつかの一般的な TFVC 分岐シナリオの確認が完了しました。 それらを進化させたり、機能の切り替え (機能のオンとオフを切り替えて、実行時に機能を使用できるかどうかを判断する) などの他の戦略を検討したりできます。

Q & A

ブランチの有効期間が短いのはなぜですか?

ブランチの有効期間を短く保つことで、マージの競合を可能な限り少なくできます。

必要な場合のみ分岐するのはなぜですか?

DevOps を採用するには、ビルド、テスト、デプロイの自動化を使用する必要があります。 マージの競合には手動による介入が必要になることが多いため、変更が継続的で頻繁にあると、マージ操作がより困難になります。 そのため、分岐を避け、機能の切り替えなどの他の戦略を使用することをお勧めします。

ブランチを削除するのはなぜですか?

目標は、長期的なマージの結果を軽減するために、できるだけ早く変更をメインに戻すことです。 一時的なブランチ、未使用のブランチ、過剰なブランチは、チームの混乱とオーバーヘッドを引き起こします。

コードベースはプロジェクト間で分岐できますか?

はい。 チームがソースを共有する必要があり、共通のプロセスを共有できない場合を除き、お勧めしません。

コード昇格戦略はどうですか?

コード昇格戦略は、ウォーターフォール開発時代の遺物のように感じます。 通常、テスト サイクルは長いため、開発とテストでチームは分離されています。 この戦略は今では推奨されなくなりました。 この戦略の詳細については、分岐ガイダンスに関する記事を参照してください。

開発ブランチをメイン ブランチにマージする場合、変更が検出されないのはなぜですか?

keep source 競合解決オプションを使用するなど、以前のマージの変更を無視した可能性があります。 詳細については、「開発ブランチのメインへのマージ: マージする変更がありませんでした」を参照してください。

TFVC と Git ブランチ戦略の間に類似点はありますか?

TFVC 機能分離の分岐戦略は、Git トピック ブランチに類似しています。

作成者: ALM の Jesse Houwing、Marcus Fernandez、Mike Fourie、Willy Schaub | DevOps Rangers。 こちらからお問い合わせできます。

(c) 2015 Microsoft Corporation. All rights reserved. このドキュメントは、"現状のまま" 提供されます。URL およびその他のインターネット Web サイトの参照を含む、このドキュメントの情報および見解は、予告なしに変更することがあります。 このドキュメントの使用上のリスクは、すべてユーザーが負うものとします。

このドキュメントは、Microsoft 製品の知的財産権に関する法的な権利をお客様に許諾するものではありません。 内部での参照を目的とする場合、このドキュメントをコピーして使用できます。