9

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

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

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

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

プロダクションボックスにアーティファクトを作成します

ここでは、開発者ボックスでローカルにビルドおよびデプロイするために日常的に使用されるのと同じプロセスが、本番環境にデプロイするために使用されます。

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

私は主に2番目のプロセスを使用しましたが、確かに必要があります（別の展開プロセスの時間/優先順位はありません）。個人的には、「本番ボックスですべてのコンパイラをクリーンアップする必要がある」などの議論は購入しませんが、（別のアーティファクトを作成するのではなく）テストしたものをデプロイする際のロジックを確認 できます。

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

考え？

アップデート

具体的な例を次に示します。

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

デプロイにビルドプロセスを使用する場合は、本番環境に適した構成を作成する必要があります（例production.build.properties）。

「アセンブルされたアーティファクトを本番ボックスにデプロイする」に従う場合、（誤った）OSCacheプロパティを抽出し、本番環境に適したものに置き換えるための追加のプロセスが必要になります。

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

したがって、質問は次のとおりです。

  • これは「本番環境でコンパイル」せずに回避できますか？
  • そうでない場合、これは価値がありますか？「DonotRepeatYourself」よりも「本番環境でコンパイルしない」の価値は大きいのでしょうか？
4

7 に答える 7

7

テストしたものとは異なるビルドを使用していることを意味するため、製品ボックスでのビルドには固く反対します。また、すべてのデプロイメント マシンが異なる JAR/WAR ファイルを持っていることも意味します。少なくとも、バグ追跡時にサーバー間の不一致を心配する必要がないように、統合ビルドを実行してください。

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

私が働いている場所では、展開プロセスは次のとおりです。(これは、Tomcat を使用した Linux 上にあります。)

  1. 変更をテストし、Subversion にチェックインします。(必ずしもこの順序ではありません。コミットされたコードをテストする必要はありません。フルタイムの開発者は私だけなので、SVN ツリーは基本的に私の開発ブランチです。マイレージは異なる場合があります。)

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

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

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

于 2008-09-26T21:10:59.347 に答える
3

私が働いた場所のほとんどは、環境固有の構成情報を戦争/耳の外で個別に展開した (そしてほとんど更新されなかった) 最初の方法を使用していました。

于 2008-09-26T20:32:44.337 に答える
1

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

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

于 2008-09-26T20:32:37.257 に答える
1

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

于 2008-09-26T20:39:55.100 に答える
1

私は、分散ビルドをサポートする継続的インテグレーション ソリューションの使用を支持します。SCM にチェックインされたコードはビルドをトリガーし (即時テスト用)、ビルドをスケジュールして QA 用のアーティファクトを作成できます。その後、これらのアーティファクトを本番環境に昇格させ、デプロイすることができます。

これは現在、 AnthillProを使用してセットアップに取り組んでいるものです。

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

于 2008-09-26T22:03:26.960 に答える
0

構成管理に関連してこの質問をしている場合は、管理されたアーティファクトと見なされるものに基づいて答えを出す必要があります。CM の観点からすると、ソース ファイルの一部のコレクションが、ある環境では機能し、別の環境では機能しないという状況は容認できません。CM は、環境変数、最適化設定、コンパイラとランタイムのバージョンなどに敏感であり、これらのことを考慮する必要があります。

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

具体例の更新

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

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

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

通常、展開場所に固有の展開構成要件を維持しようとします。

于 2008-09-26T21:08:40.163 に答える
0

デプロイには 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 つのプロセス、実際には蟻塚のボタンの 1 回のクリック。

于 2008-10-06T22:06:06.107 に答える