ナゲットの機能ブランチのバージョニング戦略

Question

複数のリポジトリで構成されるシステムを構築しています。それらのいくつかは一般的です。このソリューションは、.NETテクノロジ、ナゲット、およびジンキンサーバーで構築されています。

バージョン管理を導入する予定です。すべてのバイナリにはMajor.Minor.Patch.Buildのような製品バージョンが必要です。

CIサーバーに専用のNugetサーバーを用意し、一般的なプロジェクト用の内部パッケージを公開します。同様に、開発者のローカルマシンにナゲットサーバーを作成します。ここで

は、問題のシナリオです：

サポート1人の開発者が長時間実行機能ブランチに取り組んでいます。また、この機能では、複数のブランチ（共通ブランチを含む）にわたる変更が必要です。開発者は両方のリポジトリの機能ブランチを作成し、それらのリポジトリの作業を開始します。

機能ブランチをビルドするジョブがあるため（コミットが行われるたびにまたはCIサーバーでプルリクエストが発生するたびに）、CIサーバーは共通リポジトリ用の集中型ナゲットサーバーにナゲットパッケージを作成します。

生成されたnugetパッケージのバージョンが（前のバージョンと同じ）場合は、既存のパッケージが置き換えられます。

バージョンが異なる必要があります。ビルド部分のように、以前のバージョンの任意の部分を増やすことも、バージョン番号の末尾に-featureNameを追加することもできます。どちらが優先されるべきですか？

また、これらの2つのことをdevマシンでも行う場合、開発者はブランチ間で切り替えるたびにパッケージ参照を変更する必要があります。したがって、理想的には、devマシン上で生成されたパッケージは、以前のパッケージを置き換えるべきです。しかし、この場合でも、開発者はブランチ間を切り替えるため、適切な共通パッケージを作成する必要があります。

このシナリオでは、標準的な解決策を提案してください。あなたは簡単にトポロジやブランチ名をコミットgitのに基づいて、異なるバージョンとそれぞれの新しいパッケージを生成するのに役立つ可能性があり「GitVersion」（https://gitversion.readthedocs.io/en/latest/）に顔をしている可能性がAdvnace

Answer 1

に

感謝。

それぞれのプッシュでは、異なる名前のパッケージが作成されます。

特に、ナゲットは最新バージョンのSemVer V2をサポートしています（必要に応じて更新）。

また、「トランクベースプログラミング」を見て、ブランチを少なくする機能を切り替えると、開発が簡単になります。

また、おそらく「モノレポ」に役立つ可能性もあります。