git、maven、jenkins-バージョン管理、開発、リリースビルドのワークフロー
Git、maven、およびjenkinsで以下を実行するための推奨される方法は何ですか？
「dev」と「release」のブランチを維持したいアプリケーションを開発しています。ジェンキンスに両方を作成して欲しい。これは、リリースアーティファクトのバージョンが1.5.2になり、dev-buildが0.0.1-SNAPSHOTになるようにするためです。 2つの異なるpom.xmlファイルを用意する必要はありません。
プロファイルを調べましたが、アーティファクトのバージョンを変更できないようです。私が見た1つの方法は、テストビルドに「修飾子」を追加することでした。もちろん、ファイル名を変更することもできます。これは、アプリがスタンドアロンのものであるため、これに関する実際のアーティファクト情報は重要ではないためです。
これを行うための好ましい方法は何でしょうか？またはどのようにこれを行いますか？
バージョン番号の問題に対処するために、これらのブランチ間に固有の関係があるはずだと思います。
解放する
Devブランチからreleaseブランチに本番環境対応のコードをマージしてから、（Jenkins経由または手動で）Mavenリリースを実行することを想定しています。これにより、自動的にバージョン番号が次のビルドに移ります。したがって、コード1.4.7-SNAPSHOTをこのブランチにマージし、リリースを実行してバージョン1.4.7をカットすると、Mavenが作業コピーを1.4.8-SNAPSHOTに自動的にロールします。
ベースラインの更新（オプション）
リリースの場所としてトランク（またはベースラインブランチなど）をまだ使用していない場合は、リリースが完了したらすぐにトランクを更新する必要があります。つまり、バージョン番号も更新されます。リリースブランチをベースラインと見なすだけの場合、この手順は意味がないかもしれません。
ベースラインからDevブランチへのアップマージ
開発ブランチがactual製品コードで最新の状態に保たれることが不可欠です。ベースライン（または実装によってはリリースブランチ）から開発ブランチまでのコードをマージする必要があります。これは、リリースプロセス中に発生した、バージョンを1.4.8-SNAPSHOTに変更したpomの変更がこのブランチにもたらされることを意味するため、あなたのケースでは重要です。
私が読んだ（および私の組織でのプロセス）に基づいて、これはMavenのリリースとスナップショットのかなり標準的で効果的な使用のようであり、さまざまなブランチで完全に切断されたバージョン番号を維持するのではなく、簡単にわかります1.4.7-SNAPSHOTビルドは、実際には1.4.7リリースのすぐ前のものでした。それらは関連しています。あなたがこれらのブランチの間で行ったり来たりしてマージしていないとしたら、私は言うまでもありませんSCMとMavenの両方のバージョン管理を間違っていますそして、あなたは開発のリスクにさらされていますプロダクションと一致しないコード、バグをプロダクションに再導入するなど.
あなたのアプローチを再考してください。
使用することは非常に一般的です。 1.4.2をリリースバージョンに、次に1.4.3-SNAPSHOTを次の開発に使用します。
maintain release 1.4.2が必要な場合は、1.4.2アーティファクトを生成したコミットからブランチを分岐させます。
次に、Jenkinsにリポジトリの場所とブランチ名を伝え、ファイルセットをチェックアウトします。次に、Jenkinsにプロジェクトでmavenを使用してビルドするように指示します。
注：単一のpom.xmlを使用して実際のアーティファクトを作成し、別のpom.xmlを使用して実際のビットを作成して顧客に届けることが非常に有益であることがわかりました。