同じプロジェクトの複数のクライアントに対する分岐モデルの提案

Question

さまざまなクライアントのベースとして機能するいくつかのアプリケーションを含む非常に大きなプロジェクトがあります。

すべてのクライアントは、製品の独自のパーソナライズ、異なるマイルストーン、異なる要件などを持っているため、各プロジェクトは独自のニーズに基づいて独立して進化します。

プロジェクトの中核は、すべてのプロジェクトでsimilar（ただし等しくない）であり、組織は各クライアントを個別に処理するチームが存在するように作られています（しかし、必要に応じてそれらの間でコミュニケーションをとります）。これまでのところ、インターネットを検索したり、すばらしいアイデアを思いついたりして、ニーズに合ったスキームを見つけることができませんでした:)

これまでのところ、すべてのニーズに合った製品として、必要な変更のために特定のブランチを用意することで取り組んできましたが、製品には優れたアーキテクチャーがありますが、徐々に大きな問題になりつつあります。私たちが直面する主な問題は次のとおりです。

クライアントごとに異なるマイルストーン：つまり、残りのコミットが安定性や製品に影響を与えることなく、各チームが異なる時間にバージョンを作成する必要があります。
システムのコアに影響する場合とそうでない場合がある異なる要件。
大規模チーム（20人以上のチームメンバー）
システムのバグの処理：他のクライアントに影響を与える可能性のあるプロジェクトのバグをチームが見つけた場合はどうしますか？

注： 10 + MのLOCを持つプロジェクトについて話しています。

注： Team Foundation System、Visual Studio 2008、およびC＃（主に）を使用しています。

状況に対処する方法についての提案、情報源、またはアイデアはありますか？同様の問題があるモデルが市場にありますか？

Deckard · Accepted Answer

実際には、分岐モデルは必要ありませんが、システムに関する多次元制約に対処するための完全な包括的なアプローチwithout分岐。実際には、いくつかの共通点はあるが、ブランチで異なるように進化する複数のシステムを維持することは常に問題となるので、すべてを1つのシステムに変えて、全体として進化するが、異なる構成で構成することをお勧めします。これは単純すぎるように見えるかもしれませんが、多くの成功した産業アプリケーションで、この分野で広範な研究があります。

このアプローチの名前はSoftware Product Linesまたは時々Product Line Engineeringです。。 CMU SEIのソフトウェア製品ラインのページから：

ソフトウェア製品ライン（SPL）は、特定の市場セグメントまたはミッションの特定のニーズを満たす共通の管理された機能のセットを共有し、所定の方法で共通のコア資産のセットから開発された、ソフトウェア集約型のシステムのセットです。。

重要なアイデアは、すべての要件、すべてのマイルストーン、すべてのfeature（このドメインの重要な用語）は、最高レベルの完全なシステムの一部であるということです。さまざまな顧客に展開されている実際のシステムは、基本的に機能の集まりです。ただし、各機能はシステムにマッシュされた物理的なコンポーネントだけではなく、他の機能に依存するか、他の機能によって有効になるように定義されています（機能を選択することで、その依存関係などを自動的に含めることができます）。

その後、これらすべてのブランチを保守する代わりに、お客様固有の構成のセットとともに1つのシステムを保守することになります。

非常に大規模なシステムでこのようなアプローチに移行することは実際には困難または不可能でさえあるかもしれませんが、それでも、SPLで使用されているアプローチを調査して、少なくとも（部分的に）使用できるアプローチを評価することは有用です。あなたの仕事に統合されています。

その他の便利なリンク：

Ladislav Mrnka · Answer

私が最初の仕事を始めたとき、私は同様のプロジェクトに取り組みましたが（ただし規模は小さい）、同じ問題に直面しました。また、すべてのクライアントの一般的なソリューション処理要件から始めましたが、それは要件が矛盾する同じ時点までしか可能ではありませんでした。私たちはあなたが提案したことを行い、クライアントごとに個別のバージョンを開始しました。これでも要件とカスタマイズの問題は解決され、バグやグローバルな変更を解決するためのメンテナンスの悪夢になります。

アプリケーションのコードは類似しているだけなので、ある顧客バージョンから別のバージョンへの変更のマージは非常に複雑で、各バージョンを個別に再テストする必要がありました（自動テストはありませんでした！）。異なるバージョンでしばしば回帰バグを引き起こしました。あなたのシナリオでは、1つのチームがバージョンのバグを解決し、別のチームが完全に理解していないバージョンからその変更をマージする必要があるため、これはさらに悪化する可能性があります（私たちは1つのチームがすべてのバージョンに取り組んでいました）。

共有グローバルコアがない限り、同じ問題が発生します。私が会社を辞める前に、私たちのアプローチが間違っていることがわかりました。このような開発シナリオをサポートするには、上位のカスタマイズ可能なアプリケーションレイヤーから構成可能な共有の拡張可能なコアとデータモデルが必要でした。このコアは、各顧客固有のカスタマイズのベースとして使用し、別のチームで保守する必要があります。複数のプロジェクトマネージャーが同じチームのリソースを必要とするため、管理上の複雑さが含まれますが、アーキテクチャを一貫性のあるものにし、プロセス全体を制御し、バージョンの同期を保つ唯一の方法です。

Marjan Venema · Answer

私は基本的な方法かもしれませんが、システムのコアで直面しているのは、コンポーネントを使用し、ソフトウェアの異なるリリースを維持およびサポートする必要があるすべての人が直面する同じ問題であり、それらの異なるリリースにはそれぞれ異なるセットが必要だと思いますコンポーネントのバージョンの。

例えば

リリース1.0には、ライブラリA 1.0、ライブラリB 2.0、ライブラリC 5.6が必要です
リリース2.0には、ライブラリA 1.0、ライブラリB 3.7、ライブラリC 5.7が必要です
リリース3.0には、ライブラリA 1.2、ライブラリB 3.7、ライブラリC 5.8が必要です

コンポーネントの問題を解決する方法は、バージョン管理システムにライブラリのすべてのバージョンを用意し（ソースでビルド）、検索パス（参照パス？）を変更して各プロジェクトに適切なライブラリバージョンを使用させることです。

Delphiでは、設計時にライブラリが必要ない場合、プロジェクトの構成ファイル（ソース管理下）を介してこれを簡単に実行できます。そうしないと、実行可能ですが、Delphiを切り替える必要があるため、少し面倒になりますIDE正しいバージョンを使用するためにも（バージョン管理下の登録（.reg）ファイルは、ここで救いに来ることができます）。

コアシステムのソリューションは、異なるバージョンを維持するためのライブラリとして扱うことです。つまり、バージョンごとに異なるブランチをセットアップする必要があるということです。クライアントのアプリケーションは、適切なコアシステムのブランチフォルダを参照することにより、コアシステムの適切な「バージョン」を使用できます。

コアシステムの依存関係が上記の例に似ている場合、クライアントアプリケーションの依存関係には、コアシステムのバージョンという追加の参照があります。

ここで複数のクライアントアプリケーションに追加された利点は、コアシステムの特定のバージョンの使用をいつ開始するかを選択できること、および特定のクライアントアプリケーションでまだ使用する準備ができていないコアシステムへの変更の影響を受けないことです。