メンテナンスを減らすためにコードを共有する必要があるいくつかの異なるアプリケーションがあります。私はstackoverflowとWeb全般について多くのことを読もうとしましたが、これはかなり一般的な問題です。私は好きな答えを見つけていません。
私たちの TFS 分岐構造はこのようなものです。開発、メイン、プロダクションの 3 つのブランチがあります。開発ブランチでは、すべてのアクティブな開発が行われ、新しい機能の開発が完了したら、それをメインにマージしてから本番に移行します。production ブランチは、常にサーバー上で実行されるコードです。次の反復の前に修正する必要があるバグを検出した場合。変更はメインで行われ、デプロイ時にプロダクションにマージされます。コードを共有する必要があるアプリケーションは、共通の分岐階層や共通の反復スケジュールを共有していません。実際、アプリケーションの 1 つは、1 か月の反復を年に 1 回しか実行しません。（これは従来の方法とは少し異なることは承知しています。
調査中にいくつかの異なる解決策を見つけましたが、それらすべてに問題があります。
バイナリ共有: 私が見つけた一般的な方法の 1 つは、コンパイルされたバイナリを開発ブランチの下のフォルダーに分岐することでした。私の問題は、迅速に修正する必要がある共有コードのバグをどこで検出した場合、問題のコードがコンパイルされているかということです。そして、どこでバグを修正するかを決めれば、共有コード ベースにすべての変更を加えることができます。
プロジェクトの共有: ここでの私の主な問題は、許容できる方法でそれを行う方法です。私の最初のアイデアは、新しいイテレーションが開始されたときに、メイン ブランチからの変更を共有コードとマージして更新することでした。メインを開発ブランチにマージして、バグ修正の結果としての変更で開発ブランチを更新します。そして、共有コードの新しい更新バージョンを開発ブランチにブランチします。しかし、私が理解していることから、ネストされたブランチを作成するため、これは TFS ではサポートされていません。
私の質問は、いくつかの共通プロジェクトをソリューション間で共有しながらそれらを分離したままにし、共通プロジェクトが変更されて新しいバグが発生することを心配することなく、メイン ブランチのバグを修正できるようにするにはどうすればよいかということです。ただし、共通プロジェクトのバグを修正し、それらの修正を共有共通プロジェクトにマージすることはできます。