現在のソース コード リポジトリとソリューションのセットアップを簡素化することを検討しています。現在、コードは非常に複雑で巨大であり、最も単純なコードを変更するだけでも非常に時間がかかる場合があります。
簡単にするために、次の設定があるとしましょう。
- 1 つの Web サイト プロジェクト (W1) があります。
- 2 つの Web サービス プロジェクト (S1、S2) があります。
- 3 つのクラス ライブラリ プロジェクト (L1、L2、L3) があります。
それらは 3 つのソリューションによって管理されます。
- W1、L1、L2、L3 を含み、S1 および S2 へのサービス参照を使用する 1 つのソリューション
- S1、L1、L2、L3を含む1液
- S2、L1、L2、L3を含む1液
これらすべては現在、メイン、開発、およびリリース ブランチを常に使用するブランチ スキームを適用する 1 つのソース コード リポジトリによって制御されています。
ご覧のとおり、ライブラリ プロジェクトは複数回参照されており、予想どおり、複数の開発者が同じライブラリで作業している場合、衝突が発生することがあります。前に述べたように、実際にはもっと多くのライブラリ プロジェクトがあります。現在、50 以上のプロジェクトを含むソリューションがあり、ほぼすべてのソリューションに同じプロジェクトが含まれています。それらをより保守しやすくするために、ライブラリ プロジェクトを独自のソリューションに移動し、それらの NuGet パッケージを作成したいと考えています。
また、デプロイ先の環境が 3 つあります。
- 開発ブランチのビルドが毎日プッシュされる TST 環境
- リリース ブランチ ビルドがプッシュされる QA 環境
- Main ブランチのビルドがプッシュされる LIVE 環境
私が直面している問題は、1 つのスプリントの過程ですべてのプロジェクトで開発が行われ、開発者がリリース ブランチまたはメイン ブランチをチェックアウトする場合、NuGet パッケージをこの展開戦略に組み込む方法がよくわからないことです。ホットフィックスを作成するために、参照されている NuGet パッケージを台無しにして、誤って開発パッケージをメイン ブランチに導入してほしくありません。
ビルドの目的から、ライブラリ プロジェクトをビルドするときに同じ分岐戦略を使用し、各ブランチの NuGet パッケージを別のリポジトリに発行するだけで実行できます。開発者の観点からは、複数のリポジトリを簡単に切り替える方法がわかりません。別のプロジェクトまたはブランチをチェックアウトするときに NuGet リポジトリの URL を変更する必要がある開発者を煩わせることはできません。
問題は、一連のライブラリとフロントエンド プロジェクトを並行して積極的に開発する適切な方法は何かということです。
私がやりたいことがそんなに難しいことだとは思いませんし、これを望んでいるのは私だけだとは思いません。しかし、これに関する関連ドキュメントは見つかりません。私はこれを完全に間違って見ていますか？