0

ウェブアプリの継続的インテグレーション システムの展開オプションを探しています。単一の .war ファイルを構築しています。いくつかの異なる環境 (DEV、QA、STAGE など) にデプロイする必要があります。私の知る限り、環境固有のプロパティを渡す方法は 2 つあります。

まず、Tomcat の起動時に -D オプションを使用します。

-Denv=DEV

catalina.shこれには、すべての環境のスクリプトをカスタマイズする必要があります。

次に、Tomcat を起動する前に環境変数を使用します。

export env=DEV;

これには、各環境の展開スクリプトを微調整する必要があります。そして、これはプラットフォームに依存します (つまり、Windows ではあなたがしなければならないでしょうset env=DEV)。

これら2つのオプションのどちらが優れているか誰か教えてもらえますか? それとも他にもっといいのがありますか？

4

1 に答える 1

0

14 の異なる環境にデプロイされた Web アプリがあります。これを管理するために、各環境に固有のビルドを作成します。

ビルド システムとして maven を使用しているため、各環境には固有のプロファイルがあります。プロファイルは、環境によって異なる構成を含むフィルタリング用のプロパティ ファイルを参照します。この情報は、Spring コンテキスト ファイル、web.xml、weblogic.xml などにトークン化されます。

この 2 番目の部分は、Jenkins CI サーバーです。対応するプロファイルを参照する各環境のジョブがあります。これは、Subversion リポジトリでよく知られているタグ名を指しています。そのため、流れは次のようになります。

  1. 開発が行われ、コードがトランクにコミットされます。
  2. 一部の環境に組み込む必要があるため、「latest」というタグを作成します (古いコピーが存在する場合は削除します)。同時に、日時スタンプ付きのタグも作成しますが、これはオプションです。
  3. 適切な hudson ビルドを開始します。これは、一部の開発者ワークステーションからビルドしていないことを意味し、ビルドは既に構成されているため、覚えておく必要はありません。
  4. アーティファクトをプルして、Jenkins からすぐにデプロイします。

アプリ サーバー自体でアプリケーション構成が維持されているのを見たことがありますが、gluのようなものを管理する必要がない限り、維持するのはすぐに悪夢のようになります。これは、開発チームと運用チームが異なる場合に特に当てはまります。

于 2012-04-11T01:12:04.543 に答える