計画的な分岐
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
ソース コードは開発作業における重要な資産です。 しかし、複数の開発者がファイルを同時に更新する場合、効率的にソース ファイルを管理しながら開発を進めるのは困難であることがあります。 バージョン コントロール システムを使用すると、共有リポジトリへのソース コードの保存、並行開発作業の分離、コード変更の統合、および以前のファイル バージョンの復元を行うことができます。 バージョン コントロールのキー要素は、同時開発を可能にする分岐です。 戦略的に分岐を作成すれば、ソフトウェアに複数のバージョンがあっても、その順序と一貫性を保つことができます。
Team Foundation には、柔軟で信頼性の高いバージョン コントロール システムが用意されています。 Team Foundation バージョン管理を使用して、ソース コード、ドキュメント、作業項目などチームの作業対象である重要な情報の開発中に、複数のリビジョンを管理できます。
複数回のプロジェクト リリースにわたって同時に複数の変更を加える場合のチームでのコードの管理方法
バージョン コントロール システムを使用する場合は、分岐構造をどのように設定するかを検討する必要があります。 分岐は、ソース コード ファイルをミラー化することで作成できます。 作成した分岐は、ソースに影響を与えることなく変更できます。 たとえば、次の図の分岐構造が示すように、MAIN 分岐には統合テストに合格した完成済みの機能を含め、DEVELOPMENT 分岐には作成中のコードを含めます。 DEVELOPMENT 分岐の新しい機能が完成し、統合テストに合格したら、そのコードを DEVELOPMENT 分岐から MAIN 分岐に移動できます。 このプロセスを逆方向の統合と呼びます。 これに対し、MAIN 分岐から DEVELOPMENT 分岐にコードをマージするプロセスを順方向の統合と呼びます。
コード ブランチの作成およびマージ方法の詳細については、CodePlex の Web サイトの「Team Foundation Server 分岐ガイド 2.0」を参照してください。
分岐とマージには、次の基本原則があります。
それぞれの分岐には、その分岐にコードを統合する方法に関する定義済みポリシーが必要です。 たとえば、前の図の分岐構造では、MAIN 分岐を所有および管理するチーム メンバーを割り当てることができます。 このメンバーは、最初の分岐操作を実行し、DEVELOPMENT 分岐から MAIN 分岐に変更内容を逆方向で統合し、MAIN 分岐から DEVELOPMENT 分岐に変更内容を順方向で統合します。 順方向の統合は、他の分岐からの変更内容を MAIN 分岐に統合するときにも重要になります。
MAIN 分岐には、いつでもリリースできる状態になるように、統合テストに合格したコードが含まれるようにします。
DEVELOPMENT (つまり作業用) 分岐は、チーム メンバーが変更を定期的にチェックインするので、内容が常に進化しています。
ラベルは、特定の時点における分岐内のファイルのスナップショットです。
詳細については、「ラベルを使用したファイルのスナップショット取得」を参照してください。
Team Foundation ビルドでは、分岐のビルドを、手動、継続的、ゲート、ローリング、スケジュールといういくつかの種類から選択できます。 MAIN 分岐には、ゲート チェックイン ビルドを選択することをお勧めします。 これは、逆方向の統合をコミットするには、DEVELOPMENT 分岐が MAIN 分岐のすべての要件を満たす必要があることを意味します。 DEVELOPMENT 分岐では、新しいチェックインによって DEVELOPMENT 分岐が影響を受けることをチームがすぐに認識できるように、ビルドの種類として継続的なビルドを実行する必要があります。
チームによる逆方向の統合と順方向の統合の実行頻度
次の図に示すように、逆方向の統合と順方向の統合は、ユーザー ストーリーが完了するときに必ず発生します。 完了の定義はチームごとに異なる場合もありますが、通常、ユーザー ストーリーの完了とは、機能テストと、対応する単体テストの両方が完了したことを意味します。 MAIN 分岐への逆方向の統合を実行できるのは、単体テストで DEVELOPMENT 分岐の安定性が検証されてからのみです。
複数の作業 (つまり DEVELOPMENT) 分岐がある場合に、いずれかの分岐が MAIN 分岐に統合されたときは、直ちにすべての作業分岐への順方向の統合を実行する必要があります。 MAIN 分岐では安定した状態が維持されているため、順方向の統合は安全です。 作業分岐の安定性は保証できないため、作業分岐では競合やエラーが発生する場合があります。
すべての競合をできるだけ早く解決することが重要です。 MAIN 分岐にゲート チェックインを使用すると、品質ゲートが MAIN 分岐での競合やエラーの回避に役立つため、逆方向での統合がより簡単になります。 詳細については、「ゲート チェックイン ビルド処理によって制御されるフォルダーにチェックインする」を参照してください。
さまざまなユーザー ストーリーを実装するソースのチームでの管理方法
次の図に示すように、ユーザー ストーリーを完了するために、作業分岐に変更を定期的にチェックインすることができます。 同じ分岐で同時に複数のユーザー ストーリーを実装できます。 ただし、MAIN 分岐への逆方向の統合を実行できるのは、進行中の作業がすべて完了した場合のみです。 大きなユーザー ストーリーによって多くの小さなユーザー ストーリーの統合が妨げられないように、ユーザー ストーリーをサイズに応じてグループ化することをお勧めします。 たとえば、ユーザー ストーリーの 2 つのセットを 2 つの分岐に分割できます。
チームによる分岐の追加が必要になる状況
分岐の作成が必要になる状況は次のとおりです。
既存の分岐とは異なるスケジュール/サイクルでコードをリリースする必要がある場合。
コードに異なる分岐ポリシーが必要な場合。 新しいポリシーを使用する新しい分岐を作成すると、プロジェクトの戦略的な価値を高めることができます。
顧客向けに機能をリリースする場合に、チームが計画済みのリリース サイクルに影響しない変更を行うようにするとき。
統合作業の負荷が大きくなるため、ユーザー ストーリーごとに分岐を作成することはお勧めしません。 TFVC を使用するとブランチの作成は簡単になりますが、ブランチ管理のオーバーヘッドは、ブランチが多くなると著しく大きくなる可能性があります。
バージョン コントロールの観点からのチームでのリリースの管理方法
チームは、スプリントが終了するとコードをリリースできるようになります。 Team Foundation Server を使用して、ブランチにラベルを付けて、特定の時点におけるコードのスナップショットを取得することができます。 次の図に示すように、MAIN 分岐にリリースのラベルを付けることができます。 これにより、分岐をこの時点の状態に戻すことができます。
リリースに対しては更新を実装する必要があるため、1 回のリリースに対して 1 つの分岐を作成すると、将来のリリースと競合することなく、次のスプリントに対して独立してチームが作業を継続できるようになります。 更新用のコードが含まれていて、2 回目のスプリント終了時のリリース後に MAIN 分岐に逆方向に統合される分岐を次の図に示します。
リリース用に分岐を作成するときは、最も安定している MAIN 分岐から作成する必要があります。 作業分岐の安定性は保証されないため、リリース用に作業分岐から分岐を作成すると、統合時に問題が発生する場合があります。