私は2つの問題空間があると考えるのが好きです：
アーティファクトの構築（理想的には、QAがアーティファクトのハッシュを取得し、そのアーティファクトでテストを実行し、デプロイするときに、アッシュを検証して、QAが行われたことを確認できます。ビルドで異なるアーティファクトが生成される場合は、環境に依存しません。 QAの環境、ステージング環境、または本番環境のいずれであるかに応じて、本番環境に移行するアーティファクトがQAによってテストされ、ステージングでステージングされていることを確認するために、さらに作業を行う必要があります）
アーティファクトを環境に出荷します。その環境でアーティファクトの構成が必要な場合、適切な構成ファイルをターゲット環境に配置してアーティファクトに取得させるか、アーティファクトをクラックして開いて構成し、封印することにより、出荷プロセスにその構成を含める必要があります。アップ（ただし、繰り返し可能で決定論的な方法で）
Mavenは、最初の問題領域用に設計されています。「Mavenの方法」とは、環境にとらわれないビルドアーティファクトを作成し、それらをバイナリアーティファクトストアに公開することです。Mavenのライフサイクルを見ると、アーティファクトがdeployMavenリポジトリー（バイナリアーティファクトストア）に編集された後、フェーズが停止することがわかります。つまり、Mavenはその仕事がその時点で完了したと見なしています。testさらに、統合と統合にはライフサイクルフェーズがあり、integration-testどちらも環境に依存しないアーティファクトで可能であるはずですが、それは必要なテストの完全なセットではありません...テストを完了するには、実際にデプロイする必要があります。構築されたアーティファクトを実際の環境に組み込みます。
多くの人がMavenを乗っ取って、その目標を超えようとします（私自身も含まれます）。たとえば、Mavenエンドゲーム以外の側面に触れるとがあります（つまり、アーティファクトがMavenリポジトリに到達した後）cargo-maven-plugin。ship-maven-pluginこれらのうち、私は個人的に、 （私が書いた、以前の「自分自身を含む」を含む）は、デフォルトで、チェックしたプロジェクトのバージョンではship-maven-pluginなく、動作するように設計されているため、「aftermaven」を使用するのに最も近いと感じています-SNAPSHOTディスク上ではなく、リモートリポジトリからプルする同じプロジェクトのリリースバージョン上にあります。
mvn ship:ship -DshipVersion=2.5.1
IMO、貨物はintegration-testライフサイクルのフェーズ周辺での使用を目的としていますが、他の目的でハイジャックすることもできます。
シュリンクラップされたソフトウェア、つまりユーザーが購入してシステムにインストールするソフトウェアを作成している場合、インストーラープログラム自体は、エンドユーザー環境向けにアプリケーションを構成するように設計されています。実際のインストーラーは（少なくともある程度）環境に依存しないため、Mavenビルドでインストーラーを生成することは問題ありません。わかりました。MicrosoftWindowsのみのインストーラーでも、Linuxのみのインストーラーでもかまいませんが、どのユーザーのマシンにインストールされるかは関係ありません。
しかし、今日では、サービスとしてのソフトウェアに集中する傾向があるため、管理するサーバーにソフトウェアを展開しています。ビルドプロファイルを使用してビルドアーティファクトの内部構成を微調整する「Mavenダークサイド」（結局のところ、デプロイ先の環境は3つしかない）に引っ張るのはより魅力的であり、高速で移動しているので、時間をかけて、アプリケーションが外部からビルドされたアーティファクトまで環境固有の構成を取得するようにします（おなじみですか？）。私がこれをダークサイドと呼ぶ理由は、あなたが本当にMavenが働きたい方法と戦っているからです...ローカルリポジトリのjarが別のプロファイルをアクティブにして構築されているかどうか常に疑問に思っているので、完全に実行する必要があります常にクリーンなビルド。pom.xml... Mavenの方法に従った場合は、リポジトリからアーティファクトを取得し、それをさまざまな環境に沿って、変更せず、変更せずに、MD5、SHA1（およびできればGPG）署名を使用して移動し、それを証明するとします。同じアーティファクトです。
だから、あなたは尋ねます、私たちはどのように生産への輸送をコーディングしますか...
この問題に取り組むにはいくつかの方法があります。それらはすべて、同様のコア原則のセットを共有しています。
古き良きbashスクリプトを使用することも、この2番目の問題領域用に設計されたchefやpuppetなどのより「最新の」ツールを使用することもできます。
推奨事項
適切な仕事には適切なツールを使用する必要があります。
それが私だった場合、これが私がすることです：
Mavenリリースプラグインでリリースをカット
構築されたアーティファクトは、常に環境に依存しない必要があります。
ビルドされたアーティファクトには、すべての構成オプションの「適切なデフォルト」が含まれている必要があります。つまり、適切なデフォルトのない必要な構成オプションが欠落している場合は高速に爆発するか、オプションのオプションが指定されていない場合は適切な方法で実行する必要があります。必要な構成オプションの例としては、データベース接続の詳細があります（アプリがメモリ内のDBで実行できる場合を除く）
シェフ対人形戦争の側面を選択してください（どちらの側面でもかまいません。必要に応じて側面を変更できます。ANTの考え方がある場合は、シェフが適しています。依存関係管理の魔法が好きな場合は、人形が適している可能性があります。より良い）
開発者は、少なくともそれらのスクリプトの環境にとらわれない部分である、デプロイメント用のchef/puppetスクリプトを定義する際に発言権を持っている必要があります。
オペレーションでは、シェフ/パペットのデプロイに関する本番環境固有の詳細を定義する必要があります
これらのスクリプトはすべてSCMに保管してください。
Jenkinsまたは任意のCIを使用して、可能な限り多くの手順を自動化します。Jenkins用にプロモートされたビルドプラグインはあなたの友達です。
最終的なゲームは、必要なすべてのテストに合格すれば、すべてのコミットが自動的に本番環境にデプロイされる可能性があることです（または、「先に進む」と言っている人のゲートを使用して）...実際にこれを行うとは言わないでくださいすべてのコミットについて、あなたができることだけ