複数の依存プロジェクトでGit Flowを使用する方法
リリース、バージョン管理などすべてが一貫して処理されるように、私たちは組織にとって効果的な分岐戦略を実行しようとしています。
多くのC＃ベースのソリューションがあり、それぞれ2から60のプロジェクトがあります。各ソリューションは、更新を定期的にリリースする特定の製品に関連しています。これらの製品にはある程度の相互依存性がありますが、それほど多くはありません。それらが交差する場合、従属プロジェクトにリソースにアクセスするためのロジックを提供するプロキシタイプのプロジェクトを伝統的に作成しました。
たとえば、他のプロジェクトがそのプロキシを呼び出すだけでよいように、エンドポイントを抽象化するためのプロキシプロジェクト（WebClientの起動、認証、およびURLへの呼び出し）を備えたWeb API Webサイトがあります。これらのプロキシプロジェクトは、関連するプロジェクトとバージョン番号を共有し、内部NuGetフィード経由でリリース/消費されます。通常、SemVerに準拠して、互換性のない変更を管理し、プロキシされたプロジェクト（Web APIなど）の適切なバージョンチェックを行って、動作が期待どおりに機能することを確認します。
この戦略はうまく機能しましたが、克服できない落とし穴が1つあるようです-リリースサイクルです。
Git Flowによると、各ソリューションのプライマリreleaseブランチからdevelopブランチを切り取ります（すべての製品を同時にリリースします）。このブランチ内で、バージョン番号をインクリメントし（変更の種類に応じてメジャー/マイナー）、内部NuGetパッケージを最新バージョンに更新します。これらのリリースブランチは、最終的なQA環境にフィードします。この環境では、すべての製品が緊急のバグについて一緒にテストされ、最終的なサインオフが行われます。
技術的には、すべてのリリースブランチを完成させ、各マスターブランチから結果のコードをデプロイできるはずです。ただし、展開されたアセンブリと使用されたアセンブリの間でバージョンの不一致が発生します。
明確にするための例：
プロジェクトAには、プロジェクトAプロキシが含まれ、依存関係がありません。プロジェクトBには、プロジェクトAプロキシを使用します。
ブランチに関係なく、すべてのコミットがプロジェクトごとに一意のバージョン番号でビルドされ、masterブランチからビルドされたアセンブリをデプロイすると想定します。
- 2つの
releaseブランチを切りました：A 1.0.0.001（これによりA 1.0.0.001およびA Proxy 1.0.0.001）およびB 1.0.0.001（これによりB 1.0.0.001）。 - どちらのプロジェクトも、バージョン番号が1つマイナーバージョン番号が1つ進んでいます：
A 1.1.0.002およびB 1.1.0.002 - プロジェクトBのNuGetパッケージを更新します：
B 1.1.0.003、現在使用中A 1.1.0.002 - テストは完了しましたが、バグは見つかりませんでした。最終的な承認は承認されました。両方のプロジェクトが
masterにマージされます：A 1.1.0.003およびB 1.1.0.004（消費するA 1.1.0.002）
ただし、バージョン番号が一致しないようになりました-A 1.1.0.003、しかし消費しているA 1.1.0.002。この場合、これらにはまったく同じコードが含まれており、バージョン番号の違いは分岐マージによるものであると想定できる可能性がありますが、ここではそうですが、常にそうであるとは限りません。
以前は、これに対処する方法は、依存関係チェーンの順序でリリースブランチを順番にマージし、依存プロジェクトを更新することでしたが、リリースサイクルの上流でバグが見つかった場合、外部にパッチを適用する方法がありませんhotfixブランチ（コードは技術的にまだデプロイされていないため意味がないようです-依存製品のためにまだテスト中であり、まだ完全にサインオフされていません）。
どうすればこのパラドックスを解決できますか？製品間の依存関係があるため、すべての製品リリースサイクルを同期させる必要がありますが、各製品および依存関係について、テストおよびサインオフされたバージョンがリリースされたバージョンであることを確認する必要もあります。
どのようにして突然バージョンB 1.1.0.003になったのかはよくわかりませんが、これを必要以上に複雑にしていると感じずにはいられません。あなたは自分のプロジェクトのすべてが一度にリリースされると自分で言いました、そしてそれはおそらくプロジェクトがお互いに持っているように見える依存関係のクモの巣のためです。プロジェクトAのホットフィックスに対する単一の変更は、プロジェクトBがプロジェクトAのバージョン依存関係を新しいホットフィックスバージョンに更新し、プロジェクトBに新しいホットフィックスバージョンを持たせるなどのダウンストリーム効果をもたらす可能性があるようです。 。
ブランチを開発
1つのプロジェクトの開発ブランチについて考える方法は、そのソフトウェアコンポーネントの次のメジャーバージョンまたはマイナーバージョンに向けて継続的に開発することです。これが徹底的にテストされ、最終的なQAテストの準備ができて初めて、新しいリリース番号をコミットする必要があります。
リリースブランチ
新しいリリース番号をコミットし、すべてが順調に進んだら、メジャーまたはマイナーバージョン番号を増やし、依存関係を更新します。ついに公式になりましたが、これらのコンポーネントは製品化されます。いつでもdevブランチをリベースでき、devブランチには最新の本番バージョン番号があり、Releaseブランチで解決された最新のバグ修正があります。
修正プログラムブランチ
基本的にリリースと同じですが、ソフトウェアコンポーネントバージョンの更新またはパッチ番号を変更します。
Nugetビルド番号で救出
正式なバージョン番号は、安定した「完全な」コードのためにのみインクリメントまたは変更する必要があります。他のすべてのコードは開発中に考慮されるため、現在開発中の依存関係の変更を管理するときは、Nugetのツールを使用して、バージョンとビルド番号の依存関係を参照する必要があります。ビルド番号は本質的に一時的なものであり、ReleaseをMasterにマージする前に削除することができます。 Paketのように、これをさらにうまく行う他のツールがあることを理解しています。
atomic change flow を使用して複数のリポジトリで同期し、過去に同様の状況で成功しました。
基本的な考え方は、できる限りアトミックな変更を独自のブランチに保持することです。中間の「リリースアセンブリ」ブランチを使用して同期の複雑さを軽減し、地獄をマージすると、開発（または同様の補助ブランチ）はいつでも破棄でき、製品にデプロイされたときにのみマスターにマージされます。
バージョン番号を正確に作成する方法がわかりません。マージが早送りマージになる可能性がある場合にも、新しい番号が作成されますか？そうでない場合は、手順4でマージを行うことで問題を解決できる可能性があります。マージは、早送りマージである可能性があります。 Git Flow が使用されるため、実際にはこのマージは早送りマージになることはありません
git merge --no-ff release
マスターブランチにマージするとき。
主なポイントは、手順4でマージを引き起こす可能性のあるマスターブランチに何かがあるかどうかだと思います。早送りできませんでした。このマージが早送りマージではない場合、マスターではリリースブランチでテストしたものとは異なる何かで終了します。 Gitフローに正しく従うと、適用される変更の順序のみが異なります。 （最初の修正プログラムの時点で、developブランチにすでにいくつかのコミットがある可能性があります。）
マスターが作成された後、すべてのホットフィックスがマスターにプッシュされた後で、マスターをリリースブランチにマージできます。これにより、手順4のマージが早送りマージになる可能性があります。
整理する最後のことは、早送りされる可能性のあるマージに対して新しいバージョン番号を生成しないようにバージョン管理を調整することです。私はこれについての経験がありません。私はあなたの問題について考えています。重要なことを逃したかもしれません。