GitFlowでのMavenバージョン管理

Question

Git Flowは長い間存在しており、多くの人がお気に入りのgitワークフローとしてGitFlowを採用しているようです。

Java/Maven設定でGitフローを実装することになると、以下のすべてのブランチにあるソフトウェアモジュールのバージョン管理にどのように取り組むべきか疑問に思いました。

単純なMavenの世界では、

開発者は常にSNAPSHOTバージョンで作業します（例：0.0.1-SNAPSHOT）
一部のリリースプロセスでリリースが作成されます（0.0.1）
開発者が（0.0.2-SNAPSHOT）で開発できる新しいスナップショットバージョンが利用可能になります。

開発ブランチとマスターブランチだけがあれば問題ありませんが、GitFlowでMavenバージョン管理をどのように処理しますか。

マスターのバージョンは、最終的にリリースブランチから作成およびリリースされるバージョンになるため、定義は非常に簡単です。

しかし、コードがリリースブランチに移動するとすぐに、ここでどのバージョン管理戦略を展開しますか？

Developとの競合を避けるために、リリースブランチで新しいバージョン番号を予約する必要があると思いますか？そして、そのバージョン番号は、開発ブランチにあるものとどのように関連しますか。
リリースブランチでは、リリースが本番環境に移行する前に複数のコミットが存在する可能性もあると思います。スナップショット以外のバージョンを再利用することはできないので、コミットごとにここで固定バージョンをインクリメントしますか、それともファイナライズしてマスターにプッシュする前にリリーススナップショットバージョンで作業しますか？
変更をリリースから開発ブランチにマージするとき、新しいスナップショットバージョンを開始しますか？

Ananthapadmanabhan · Answer

このアプリケーションでは、maven-release-pluginを使用してpomファイルのバージョンを更新していました。 Jenkinsのようなツールを使用している場合、ジョブを構成するたびに、ダウンストリームジョブをトリガーするためのプロビジョニングもあります。したがって、この場合、次の設定があります。

releaseからmasterへのプルリクエストが行われ、ビルドはリリース時に実行され、成功するとマージが可能になります。
マージが発生すると、pom内のバージョンをスナップショットバージョンに更新するためにjenkinsジョブがトリガーされました。この後、ダウンストリームジョブがトリガーされ、developブランチの同じスナップショットバージョンも更新されました。

したがって、私たちの場合、リリースが2つのバージョン更新を経るたびに、1つはリリースバージョンがカットされたとき、もう1つはリリース後にマスターと開発にマージするときにスナップショットバージョンがカットされたときです。したがって、マスターとリリース後に開発する場合、最終バージョンは常にスナップショットバージョンになります。一部のチームでは、開発時にスナップショットバージョンのみを更新し、リリースバージョンをマスターに直接プッシュすることを確認しました（つまり、スナップショットにバージョンを変更せずに、masterからreleaseにマージします。ダウンストリームジョブは、developにマージするときにバージョンをスナップショットに変更します）。

あなたの質問について：リリースブランチでは、リリースが本番環境に入る前に複数のコミットが存在する可能性もあると思います。スナップショット以外のバージョンを再利用することはできないため、コミットごとにここで固定バージョンをインクリメントしますか、それともファイナライズしてマスターにプッシュする前に、リリーススナップショットバージョンでも機能しますか？

理想的なケースでは、リリースブランチは直接コミットしません。そのため、開発を経て開発を行う必要があります。そのため、開発からリリースにマージするたびに、プロセスとしてセットアップされるため、バージョンをインクリメントする必要があります。また、バグ修正と機能をそれぞれずつインクリメントすると、バグ修正と機能を追跡しやすくなります。リリース。

scrutari · Answer

ソース管理（Gitが管理）と建物（Mavenが管理）の領域を分離しておくことが重要だと思います。つまり、バージョン管理とブランチの管理は、_pom.xml_ファイルの外部で行う必要があります。それでもいくつかのMavenプラグインを使用して実現できますが、このプラグインはビルドプロセスの一部ではなく、このプロセスの外部のツールである必要があります。

そうは言っても、Mavenバージョンのこの説明を見てください。リリースブランチが作成されると、バージョン_X.Y.Z_がこのリリース用に「予約」されます（そしてdevelopブランチはアトミックに増分スナップショットバージョンX.Y.(Z+1)-SNAPSHOTまたはX.(Y+1).Z-SNAPSHOTなど、次のリリースの種類によって異なります）。その間、リリースブランチはしばらくの間存在し、競合を回避するためにビルド間でアーティファクトのバージョンを変更する必要がある場合があります。これは、ビルド番号または修飾子とビルド番号を一緒に使用することで実行できます。たとえば、_X.Y.Z-alpha-0_から開始して、_X.Y.Z-beta-0_以降に変更するまで続行できます。「プレリリース」アーティファクトをリポジトリにデプロイする必要があるたびに、ビルド番号をインクリメントします。最終的に、リリースが行われると、バージョン_X.Y.Z_は、ビルド番号と修飾子を持つすべてのバージョンよりもMavenによって「大きい」と見なされます。