Java Web Deployment：コードをビルドするか、.warをデプロイしますか？

Question

J2EE / Java Webアプリをデプロイする2つの主な方法（非常に単純な意味で）：

組み立てられたアーティファクトをプロダクションボックスにデプロイする

ここでは、 .war （またはその他）を別の場所で作成し、本番用に構成し（場合によっては多数のボックス用の多数のアーティファクトを作成し）、結果のアーティファクトを実動サーバーに配置します。

• 長所：実稼働ボックスには開発ツールがなく、テストからの成果物を直接再利用できます。展開を行うスタッフはビルドプロセスの知識を必要としません
• 短所：アーティファクトを作成およびデプロイするための2つのプロセス。事前に構築されたアーティファクトの潜在的に複雑な構成により、プロセスのスクリプト化/自動化が困難になる可能性があります。バイナリアーティファクトをバージョン管理する必要があります

プロダクションボックスで アーティファクトを構築します

ここでは、開発者ボックスでローカルにビルドおよび展開するために日々使用されているのと同じプロセスが、実稼働環境への展開に使用されています。

• 長所：維持する1つのプロセス。そして、頻繁に使用することで徹底的にテスト/検証されています。ビルド済みのアーティファクトの後書きをカスタマイズするよりも、アーティファクトの作成時に構成をカスタマイズする可能性があります。バイナリアーティファクトのバージョン管理は必要ありません。
• 短所：すべてのプロダクションボックスで必要となる可能性のある複雑な開発ツール。展開スタッフはビルドプロセスを理解する必要があります。テストしたものを展開していない

私は主に2番目のプロセスを使用しましたが、明らかに必要ではありません（別の展開プロセスの時間/優先順位はありません）。個人的には、「プロダクションボックスはすべてのコンパイラなどを削除する必要があります」などの引数を購入しませんが、テストしたものを展開する際のロジックを 見ることができます別のアーティファクトを構築する）。

ただし、Java Enterpriseアプリケーションは設定に非常に敏感であるため、アーティファクトを設定するための2つのプロセスが問題を抱えているように感じます。

思考？

更新

具体例を次に示します。

OSCacheを使用して、ディスクキャッシュを有効にします。構成ファイルは.warファイル内にある必要があり、ファイルパスを参照します。このパスは環境ごとに異なります。ビルドプロセスは、ユーザーが構成した場所を検出し、warに配置されたプロパティファイルがユーザーの環境に合っていることを確認します。

展開にビルドプロセスを使用する場合、実稼働環境に適切な構成を作成する必要があります（例： production.build.properties ）。

「組み立てられたアーティファクトをプロダクションボックスにデプロイする」に従う場合、（不適切な）OSCacheプロパティを抽出し、プロダクション環境に適したものに置き換えるための追加プロセスが必要になります。

これにより、同じことを達成するために2つのプロセスが作成されます。

つまり、質問は次のとおりです。

• 「本番環境でコンパイルする」ことなくこれは回避できますか？
• そうでない場合、これは価値がありますか？ 「本番環境でのコンパイルなし」の価値「自分自身を繰り返さない」よりも大きいですか？

Answer 1

私は、実稼働環境でのビルドに固執します。テストしたものとは異なるビルドを使用しているからです。また、すべての展開マシンに異なるJAR / WARファイルがあることも意味します。それ以外の場合は、バグ追跡時にサーバー間の不整合を心配する必要がないように、統合ビルドを実行します。

また、ビルドとビルドを作成したソースとの間を簡単にマップできる場合は、ビルドをバージョン管理に入れる必要はありません。

私が働いている場所での展開プロセスは次のとおりです。 （これは、Tomcatを使用したLinux上で実行されます。）

1. 変更をテストし、Subversionにチェックインします。 （必ずしもその順序である必要はありません。コミットされたコードをテストする必要はありません。私が唯一のフルタイムの開発者であるため、SVNツリーは本質的に私の開発ブランチです。 li>

2. JAR / WARファイルを、Subversionリビジョン番号にちなんで名付けられた共有ディレクトリ内のプロダクションサーバーにコピーします。 Webサーバーには読み取りアクセスのみがあります。

3. 展開ディレクトリには、リビジョン名のディレクトリ内のファイルへの相対シンボリックリンクが含まれています。そうすれば、ディレクトリリストには常に、実行中のバージョンを生成したソースコードのバージョンが表示されます。デプロイするとき、ディレクトリのリストにすぎないログファイルを更新します。これにより、ロールバックが簡単になります。 （ただし、Tomcatは、シンボリックリンクではなく、実際のファイルの変更日までに新しいWARファイルをチェックするため、ロールバックするときに古いファイルに触れる必要があります。）

当社のWebサーバーは、WARファイルをローカルディレクトリに解凍します。 WARファイルは単一のファイルサーバー上にあるため、このアプローチはスケーラブルです。 Webサーバーの数に制限はなく、単一の展開のみを実行できます。

Answer 2

私がこれまで働いてきた場所のほとんどは、戦争/耳以外で個別にデプロイされた（そして非常にまれに更新された）環境固有の構成情報で最初の方法を使用しました。

Answer 3

「組み立てられたアーティファクトをプロダクションボックスにデプロイする」ことを強くお勧めします。 warファイルなど。これが、開発者が同じビルドスクリプト（この場合はAnt）を使用して、最終的なアーティファクトの作成に使用されるのと同じように、開発サンドボックスに戦争を構築する理由です。このようにして、コード自体だけでなく、完全に反復可能なのは言うまでもなくデバッグされます。

Answer 4

重量 ZooKeeper などの構成サービスが存在し、ほとんどのコンテナーが有効になっていますJNDIを使用して設定を行う必要があります。これらはビルドから構成を分離しますが、やり過ぎになる可能性があります。ただし、それらは存在します。ニーズに大きく依存します。

また、アーティファクトが構成値のプレースホルダーで構築されるプロセスを使用しました。 WARがデプロイされると、展開され、プレースホルダーが適切な値に置き換えられます。

Answer 5

分散ビルドをサポートする継続的統合ソリューションの使用を支持します。 SCMにチェックインされたコードは、ビルドをトリガーし（即時テスト用）、ビルドをスケジュールしてQAの成果物を作成できます。その後、これらのアーティファクトをプロダクションにプロモートし、デプロイすることができます。

これは現在、 AnthillPro 。

編集：現在、 Hudson を使用しています。強くお勧めします！

Answer 6

構成管理に関連してこの質問をしている場合、答えは管理対象の成果物であると考えるものに基づいている必要があります。 CMの観点からは、あるソースファイルのコレクションをある環境で動作させ、別の環境では動作させないことは受け入れられない状況です。 CMは環境変数、最適化設定、コンパイラーおよびランタイムのバージョンなどの影響を受けやすいため、これらを考慮する必要があります。

繰り返し可能なプロセスの作成に関連してこの質問をする場合、答えは許容できる痛みの場所と量に基づいている必要があります。 .warファイルを使用すると、テストと展開のサイクルで労力を節約するために、より多くの前払いの痛みが伴う場合があります。ソースファイルとビルドツールを使用すると、初期費用を節約できますが、展開プロセスの後半で問題に対処する際の追加の痛みに耐える必要があります。

具体例の更新

例に関連して考慮すべき2つのこと。

1. .warファイルは、代替拡張子を持つ.zipファイルです。標準のzipユーティリティを使用して、構成ファイルを所定の場所に置き換えることができます。

2. .warファイル内に構成ファイルを配置する必要性を再考する可能性があります。それをクラスパスに配置するか、サーバーの起動時に実行コマンドラインでプロパティを指定するだけで十分でしょうか。

一般に、私は展開場所に固有の展開構成要件を維持しようとしています。

Answer 7

1つのパッケージ化されたwarファイルをデプロイに使用することをお勧めします。
antを使用して、環境間で異なる値を置き換えます。 antスクリプトに置き換えられる@@@変数でファイルをチェックインします。 antスクリプトは、ファイル内の正しいアイテムを置き換えてから、各ファイルにデプロイする前にwarファイルを更新します

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

要約すると、antはそれをすべて行い、anthillを使用してantを管理します。 antはwarファイルをビルドし、ファイルパスを置き換え、warファイルを更新してから、ターゲット環境にデプロイします。 1つのプロセス。実際には、anthillのボタンをクリックするだけです。