0

私は、大企業向けの Java エンタープライズ Web アプリケーションを提供する比較的小規模なコンサルタント会社で働いています。最近のお客様との会合で、リリース プロセスをお客様の作業方法に合わせて調整する方法についていくつかのアイデアを考えました。

アプリケーション プラットフォームごとに、通常、アプリケーションが展開される開発、テスト、および運用環境があります。さらに、開発のほとんどを行うローカル開発環境があります。

現在のアプローチでは、環境ごとに 1 つずつ、4 セットの構成データを用意しています。いずれかの環境のリリースを準備する場合は、構成を交換し、maven を使用して tomcat サーバーにデプロイするための war ファイルを生成します。さらに、バージョン管理には git を使用します。

このプロセスを 1 つの全体的なビルド プロセスに自動化したいと考えていますが、どのアプローチを取るべきかについてフィードバックをいただければ幸いです。

構成

  • 構成を war ファイルの一部としてビルドに統合するか、それとも外部化して Web アプリケーションにフィードする必要がありますか? これはmavenを使用してどのように実現できますか?
  • マルチプラットフォーム構成の違いをどのように処理していますか? (例: ビルド プロセスの一部としてのフラグ ベースのアプローチ)

アーティファクト生成

  • 私の目標は、インストール パスを制御し、インストールを元に戻すことができるように、war ファイルの代わりに各環境の rpm を提供することです。これは一般的な方法ですか?

バージョン管理

  • バージョン管理には git を使用し、単一のリポジトリに dev、stage、および release ブランチを配置しています。現在、すべてのプラットフォーム構成も同じリポジトリに保存していますが、これは私の意見では、dev/stage/release ブランチとは何の関係もありません。別のリポジトリに入れるのは理にかなっていますか?
4

1 に答える 1

0

これがコンパイル時の構成である場合、something.properties ファイルを使用して駆動し、さまざまなプロパティに基づいて ant / maven に決定させることができます。

構成が実行時の場合、それぞれの web.xml または同様のファイルを介して実行できます

于 2013-10-27T15:39:46.360 に答える