安定性と革新のバランス: メインラインモデル

これまで、バージョン管理システムが、同じファイルで同時に作業するさまざまなユーザの問題に対処する方法を説明しました。異なるファイルのコピーがチェックインされるときには、最初のユーザ以外のすべてのユーザは、ファイルの最新バージョンに保持する変更を決定することで、変更を解決する必要があります。

これは並列開発の最も簡単な使用例です。大規模な開発プロジェクトで、多数のユーザが並列して作業する必要があるときには、さらに状況が複雑になります。複数のリリースをサポートする必要があり、目的の製品を作成するために協業する複数の機動チームが存在するためです。

例えば、ゲーム開発会社では、アーティスト、ミュージシャン、プログラマ、テスト担当者、ビルドエンジニアが協業してリリースを作成します。この作業を整理する1つの方法は、プロジェクトを設定するファイルのセットを複数の並列ブランチに分割することです。これにより、開発とテストを各ブランチで実行できます。次に、ブランチ全体で統合が発生し、全員の作業がリリース可能な製品に昇格します。

以下の例について検討します。

• 変化が速いWebコンテンツなどきわめて短いリリースサイクルでは、テストとリリースのサイクルが重複する必要があります。

  

  このような状況に対処するために、上記のブランチでコードを移動します。開発は開発ラインに沿って実行されます。マイルストーンに達すると、コードがQAラインにコピーされ、完全にテストされます。QAブランチがすべてのテストに合格すると、実際の環境で使用するためのベータテストラインにQAブランチがコピーされます。ベータユーザが満足すると、リリースラインにコピーできます。紫の点線は、ブランチ階層内でコピーされるコードの流れを示します。

• 予測外の遅延により、開発中の一部の機能が納期に間に合いません。プロジェクト全体に影響させずに、遅れたコンポーネントの開発が続行している間に、プロジェクトがリリースされます。

  

  上記のモデルでは、プロジェクトX、Y、Zが開発メインラインから分岐し、独立して作業が行われました。作業が完了し、プロジェクトXおよびYが開発テストに合格すると、メインラインにコピーされます。ただし、プロジェクトZは完了できず、より大規模なリリースをリスクにさらすことなく、プロジェクトZで作業を続けます。

ブランチ作成により何が提供されるべきでしょうか。安定性と革新の必要性との間でバランスを維持できます。一方で、最もテストされ安定しているコードを保有するリリースブランチがあります。他方、リリースをリスクにさらすことなく、実験と検討ができる開発ブランチがあります。

ブランチは多様な方法で整理できます。例えば、異なるプラットフォームのブランチを作成し、組織ラインに沿ってブランチを作成できます。製品開発で使用される1つの共通モデルは、以下に示すメインラインモデルです。

メインラインは、リリースブランチと開発ブランチが作成される基幹を形成します。各ブランチは、通常、メインラインファイルのサブセットを含みます。リリースブランチに含まれるファイルの数は少なくなります。テストに必要なファイルが除外されるためです。開発ブランチには異なるサブセットのファイルが含まれる場合があります。相当するプロジェクトは個別の製品機能に集中するためです。メインラインモデルでは、「上」方向は、安定性と信頼性の増加を意味します。

ブランチを作成するときには、任意の方向に自由に変更を統合できます。ただし、テストされていない変更を安定したブランチに誤って統合した場合は、大きな問題につながるおそれがあります。このため、変更を隔離するブランチを定義する他に、メインラインモデルは、どの変更がどの方向で行われるのかを制限する一部のプロトコルを実装するときに有用です。