チーム・プログラミング・モデル

通常、各チーム・メンバーは、その作業をすべて各人のワークベンチで行い、他のメンバーからは切り離されています。  最終的には、メンバーは自分の作業を他のメンバーと共用し、チームメートの変更を取得します。 これを行う場合、メンバーはストリームを使用します。

ストリーム

ストリームは、チームが自分たちの進行中の作業を共用し、統合する場所です。

ストリームは、チーム・メンバーがプロジェクトに変更を加えながら更新していく共用のワークスペースであると考えることができます。 このモデルでは、各メンバーはチームのプロジェクトに対して作業を行い、変更を加えながら自分の作業を他のメンバーと共用し、他のメンバーの作業にアクセスしながらプロジェクトを進展させていくことができます。

作業の共用

チームのメンバーは、新しい作業を作成すると、その作業に対する変更をストリームにリリース することにより、この作業を共用します。 同様に、最新の使用可能な作業が必要になった場合は、ストリーム上の変更にキャッチアップ します。  したがって、ストリームは、チームのメンバーが新規作業を投入するにつれて、絶えず変化し、進展していきます。

ストリームは、プロジェクトの現在の状態を効率よく表します。チームのメンバーは任意の時点でこの状態にキャッチアップし、それらが最新のものであることを知ることができます。

チーム・プログラミング・モデル

関連トピック:

  • 「キャッチアップ」を参照
  • 「リリース」を参照
  • オプティミスティック・チーム・モデル

    バージョン管理システムには、チームで作業を行うのに必要な重要な機能が 2 つ備えられています。

    1. チームが投入した作業のヒストリー

    2. この作業を調整し統合するための方法

    現行の作業を前の作業と比較し、たとえば古い作業の方が良かった場合にはそれに戻るようにするためには、ヒストリーの維持が重要となります。。  チームの統合化された作業を含む現行のプロジェクト状態の定義が 1 つ存在するようにするには、作業の調整がきわめて重要となります。この調整は、ストリーム・モデルを使用して行います。

    オプティミスティック・モデルとは、チームのどのメンバーであっても、アクセスできるリソースには変更を加えることができるモデルのことです。  2 人のチーム・メンバーは、ストリームの変更を同じリソースにリリースすることができるので、競合が発生することがあり、それに対処する必要があります。 このモデルは、競合はまれにしか発生しないことを前提としているので、オプティミスティック と呼ばれます。

    理想的なワークフロー

    動機付け

    通常リソースは、独立して存在することはありません。一般にリソースには、他のリソースに対する暗黙のまたは明示的な依存性が含まれています。  たとえば、Web ページには他の Web ページへのリンクが含まれており、ソース・コードは、他のソース・コードのリソースに記述されているエレメントを参照します。  いかなるリソースも孤立しているわけではありません。

    リソースがストリームにリリースされると、これらの依存関係が影響を受けます。 ストリームは現在のプロジェクトの状態を表しているので、依存関係の整合性を保証することが重要になります。このような場合、いかなる時点においても、チームのメンバーは、ストリームの内容を新規作業の基礎と見なすことができます。

    したがって、ストリームの統合性が保持されているワークフローが理想的なワークフローになります。

    理想的なフローの列挙

    理想的なワークフローは、次のように進行します。

    1. 更新を開始する: 作業を開始する前に、現行のストリーム状態にキャッチアップします。考慮すべきローカル作業がないことが確かであれば、 ストリームから必要なプロジェクトを選択し、「ワークスペースに追加 (Add to Workspace)」を選択するのが、キャッチアップする最も早い方法になります。 ローカル・リソースを、ストリームのリソースで一括上書きします。

    2. 変更を加える: 自分のワークベンチでローカルに作業を行い、新規リソースを作成し、既存のリソースを変更して、ローカルに保管します。

    3. 同期化する: 作業のリリースの準備が整ったら、ストリームと同期化します。

    4. キャッチアップする: 変更箇所を調べて、それらをローカルのワークベンチに追加します。これにより、変更が、リリースしようとしている内容の整合性に影響を与える可能性があるかどうかを判断することができます。 競合を解決します。再テスト、すなわち整合性のチェック・プログラムを実行します (たとえば、ハイパーテキストのリンクが壊れていないかを調べたり、コードがコンパイルされるかを確認する、など)。.

    5. リリースする: 変更が最新のストリームの内容と統合することができることが確認されたので、変更をストリームにリリースします。 再度新規の変更箇所があった場合は、慎重を期してステップ 4 を繰り返してもかまいません。

    もちろんこれは理想的な ワークフローです。状況によっては、変更箇所による影響がない場合には、キャッチアップしないでリリースすることもできます。 ただし、一般的には、チームのメンバーは、ストリームの整合性が誤って危険にさらされることがないようにするために、上述のようなフローに従う努力をする必要があります。