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