私は現在、しばらくの間ベータ版であった j2ee プロジェクトに取り組んでいます。現在、展開プロセスに関するいくつかの問題を解決しているところです。具体的には、戦争に埋め込まれた多数のファイル (いくつかの xml ファイルと .properties) があり、開発環境、テスト環境、または実稼働環境にいるかどうかに応じて、さまざまなバージョンの展開が必要です。ログレベル、接続プールなど。
そのため、ここの開発者が Web アプリケーションをデプロイするプロセスをどのように構築しているのか疑問に思っていました。できるだけ多くの構成をアプリケーション サーバーにオフロードしますか? 展開する前にプログラムで設定ファイルを置き換えますか? ビルド プロセス中にバージョンを選択しますか? 手動で戦争を編集しますか?
また、アプリケーション サーバーの静的ライブラリを介して依存関係を提供することについて、どこまで行っているのでしょうか。これはすべて、現時点で一般的な (またはおそらく最良の) プラクティスが何であるかについてのアイデアを得るためのものです。
プロパティがマシン/展開に固有のものである場合、それらはマシンに属していると思います。戦争で物事をまとめるつもりなら、それはドロップイン可能でなければなりません。これは、それが実行されているマシンに固有のものではないことを意味します. 戦争に機械依存の特性が含まれている場合、この考えは崩れます。
私がやりたいのは、properties.example ファイルを使用してプロジェクトを構築することです。各マシンには、戦争がアクセスできる場所にある .properties があります。
別の方法は、dev-war、stage-war、prod-war などの ant タスクを持ち、プロジェクトの一部のプロパティのセットを war-build に組み込むことです。プロジェクト ビルドの一部として、個々のサーバー上にファイルの場所などを配置することになるため、これはあまり好きではありません。
私は、別のサーバー チームがアプリケーションの QA サーバーと運用サーバーの構成を行う環境で働いています。通常、各アプリケーションは、QA では 2 台のサーバーに、本番環境では 3 台のサーバーにデプロイされます。私の開発チームは、戦争 (または耳) にできるだけ多くの構成を配置することによって、サーバーに必要な構成の量を最小限に抑えることが最善であることを発見しました。これにより、サーバーの構成が容易になり、サーバー チームがサーバーを誤って構成する可能性も最小限に抑えられます。
マシン固有の構成はありませんが、環境固有の構成 (開発、QA、および運用) はあります。環境によって名前が付けられたwarファイルに保存された構成ファイルがあります（例：dev.properties、qa.properties、prod.properties）。サーバー VM の Java コマンド ラインに -D プロパティを配置して、環境を指定します (例: java -Dapp.env=prod ...)。アプリケーションは app.env システム プロパティを検索し、それを使用して、使用するプロパティ ファイルの名前を決定できます。
少数のマシン固有のプロパティがある場合は、それらを -D プロパティとして指定することもできます。Commons Configuration は、プロパティ ファイルをシステム プロパティと組み合わせる簡単な方法を提供します。
サーバーで接続プールを構成します。すべての環境で接続プールに同じ名前を付け、各環境に割り当てられたサーバーを適切なデータベースに向けるだけです。アプリケーションは、接続プール名を 1 つだけ知っている必要があります。
wrt 設定ファイル、私はスティーブの答えがこれまでで最高のものだと思います。外部ファイルを war ファイルのインストール パスに相対的に作成するという提案を追加します。これにより、1 つのサーバーにさまざまな構成で複数の war をインストールできます。
たとえば、私dev.warが に解凍された場合、ベースフォルダーと war フォルダー名を見つけるために/opt/tomcat/webapps/dev使用するため、構成ファイルは戦争に関連して存在するか、絶対に存在します。ServletContext.getRealPath../../config/dev/opt/tomcat/config/dev
また、これらの外部構成ファイルをできるだけ少なくすることについては、 Billに同意します。環境に応じてデータベースまたは JMX を使用して、必要なだけ保存します。Apache Commons Configuration には、データベース テーブルに基づく構成を処理するための優れたオブジェクトがあります。
ライブラリに関しては、war ファイル (自己パッケージ化) 内のフォルダにすべてのライブラリを含めることは不明であることに同意します。WEB-INF/lib利点は、アプリケーションの各インストールが自律的であり、さまざまなバージョンのライブラリを同時に使用してさまざまなビルドの戦争を行うことができることです。
欠点は、各 Web アプリケーションが独自のクラス ローダーによってロードされる独自のクラスのコピーを持つため、より多くのメモリを使用することです。
これが本当に懸念される場合は、jar をサーブレット コンテナー ( $CATALINA_HOME/libTomcat 用) の共通ライブラリ フォルダーに配置できます。ただし、同じサーバー上で実行されている Web アプリケーションのすべてのインストールでは、同じバージョンのライブラリを使用する必要があります。(実際には、WEB-INF/lib必要に応じて個々のフォルダーに上書きバージョンを配置できるため、厳密にはそうではありませんが、維持するのがかなり面倒です。)
この場合、InstallShield またはNSISまたはオペレーティング システムに相当するものを使用して、共通ライブラリの自動インストーラを構築します。最新のライブラリ セットがあるかどうか、アップグレード、ダウングレードなどを簡単に確認できるもの。
通常、次の 2 つのプロパティ ファイルを作成します。
サーバーの (静的 ?) ライブラリ: サーバーへの依存関係が追加されるため、アプリでサーバー ライブラリを使用することは強くお勧めしません。
「この appserver の jar 内のこのオブジェクト」が絶対に必要な場合は、他のサーバーの jar に依存しないことを期待して、アプリ内の jar をコピーしてみてください。すべてのアプリのポリシー: サーバーの jar によって「汚染」されることはないと確信していますが、それが「ベスト プラクティス」であるかどうかはわかりません)。
すべての構成をデータベースに入れました。コンテナー (Tomcat、WebSphere など) により、最初のデータベース接続にアクセスできるようになり、それ以降はすべてデータベースから取得されます。これにより、複数の環境、クラスタリング、動的変更をダウンタイムなしで (または少なくとも再デプロイなしで) 行うことができます。特に素晴らしいのは、ログ レベルをオンザフライで変更できることです (ただし、変更を反映するには、管理画面またはバックグラウンド リフレッシャーが必要です)。明らかに、これはアプリを開始するために必要ではない場合にのみ機能しますが、通常、起動後すぐにデータベースにアクセスできます。