12

Web アプリケーションには通常、jdbc 構成とその他の設定を含む構成ファイルが少なくとも 1 つあります。このようなファイル (-s) は、.war ファイルの内部または外部に配置できます。これらのアプローチの短所と長所は何ですか? あなたのアプローチとその理由は何ですか？

4

4 に答える 4

9

同じ戦争を異なる環境で展開する必要がある場合は、外が最も便利なようです。たとえば、dev、itt、uat、および production です。同じビルドの異なる構成。

于 2010-02-26T13:18:38.557 に答える
2

私の意見では、アプリケーションの設定値をバイナリとマージするべきではありません。それらは別のファイルまたはデータベースに配置する必要があります。これは基本的なベスト プラクティスです。あなたや他の誰かが設定の 1 つをいつ調整する必要があるかはわかりません。また、あなたがそばにいない可能性もあります。また、ソース コードが利用できない場合もあります。

于 2011-11-23T18:08:35.423 に答える
1

IMHOの最善の方法は、柔軟なアプローチを使用して、構成をWARの内部および/または外部に配置できるようにすることです（構成のルックアップ順序と、構成を保持できるファイル/ディレクトリ名の追加ロジックを使用）。

私は非常に異なるデプロイモデル/スキーマの経験があります-時にはそれは1つのビルド/多くの構成であり、他の場合-でも：1つのサーバー上の多くのビルド/ 1つの構成-奇妙ですが、起こる可能性があります;-)。

これは、顧客/ユーザーがWARビルド時に指定されていないカスタム環境にデプロイできるようなプラットフォームを開発している場合に特に役立ちます。

于 2010-02-26T14:20:15.280 に答える
0

それらを戦争の中に入れて、ある種のビルドプロファイル（mavenビルドプロファイルなど）を使用します。その方法：

  • ワンステップで導入できます。リモート環境でプロパティを手動で編集する必要はありません。
  • 環境ごとに異なるアーティファクト (war ファイル) を使用できるため、ビルドは引き続き移植可能ですが、設定を変更するために ZIP ソフトウェアで war を開く必要はありません。

ビルド プロファイルを実装/使用する方法は、ビルド環境によって異なります。

于 2010-02-26T13:18:36.577 に答える