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

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

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

プロジェクトの中核は、すべてのプロジェクトで類似していますが（等しくはありません）、各クライアントを個別に処理する（ただし、必要に応じてクライアント間で通信する）チームがあるように編成されています。これまでのところ、インターネットを検索するか、素晴らしいアイデアを思いつくことで、私たちのニーズに合ったスキームを見つけることができませんでした:)

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

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

注： LOCが10M以上のプロジェクトについて話している。

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

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

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

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

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

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

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

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

その他の便利なリンク：

• ウィキペディア：製品ラインエンジニアリング
• CMU SEIによるケーススタディ
• ソフトウェア製品ライン、多くの入門資料があるサイト。

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

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

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

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

例えば

• リリース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）ファイルはここで救助できます）。

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

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

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