これは、私がさまざまな企業で見つけた一般的な問題です。
アーティファクト内にクライアント固有の構成を含む jar、war、および ear を生成します。通常、展開の方向は次のとおりです。
* Unzip the war/jar/ear
* Go to directory that contains the configuration properties.
* Rename config-prod3.properties to config.properties (or even worse, edit the config.properties file directly)
* Remove the rest of the configuration properties
* archive the deployable back up
* Now, copy it to its deployment location.
CM としての私の仕事は、ビルドとデプロイを監督することです。これらの展開コンテナを解凍して再圧縮するのは、私には悪いことだと思います。展開がより困難になり、時間がかかるだけです。
ある会社では、ビルド システムをセットアップして、環境ごとにカスタマイズされた jar/warをビルドしました。デプロイは簡単でしたが、環境の数に応じてこれらのアーカイブの数が増えるため、これには満足できませんでした。さらに、開発環境から QA、UAT、本番環境に同じ jar をデプロイしていません。はい、jar はすべて同時にビルドされ、これらのプロパティ ファイルを除いて同一ですが、本番環境にデプロイしている jar が UAT または QA 環境で直接テストされていないことに不安を覚えます。
現在の会社では、これらのアーカイブ ファイルを手動で解凍および再圧縮し、それらのプロパティ ファイルを変更する自動展開スクリプトを作成しました。これらのスクリプトは維持するのに費用がかかります。つまり、開発者がなんらかの変更 (別のプロパティ ファイルの追加など) を行った場合、デプロイが失敗するまで通知を受け取りません。
私は Java 開発者ではないので、これを処理する正しい方法がわかりません。私の最初の傾向は、すべてをデータベースに入れることです。単一のプロパティファイルは、データベースの場所をアプリに伝えるだけです。すべての値 (環境またはホスト名に基づく) がデータベースから取得されます。ただし、開発者は、これにはアプリケーションを大幅に書き直す必要があり、実装が難しすぎると言っています。(私のシニカルな心は、これを次のように解釈します。私に直接影響を与えない問題を解決してほしいですか?そんなことはありません! )。
私たちは Tomcat と JBoss を使用していますが、これらのプロパティ ファイルをサーバーの別の場所に配置して、JBoss または Tomcat の構成でそれらを追跡できるかどうか疑問に思っていました。(たとえば、 のようなもの$CLASSPATH)。この種の変更のために、開発者はどのくらいの作業を行う必要がありますか? プロパティファイルから読み取るときに絶対パスを使用しないようにしてください。それとも、これを行うのは難しすぎますか? (繰り返しになりますが、開発者は、これも複雑すぎて実装できないと言っています。)
デプロイ可能なアーティファクトからシステム固有のプロパティ ファイルを削除する最も簡単な方法は何ですか? あなたの会社では、この問題に対処するために何をしていますか?
私の問題は、私の仕事を別のグループに質入することではありません。展開をよりスムーズかつ迅速にするためです。これにより、テスト環境により多くのデプロイが可能になり、エラーが発生しにくくなります。私は展開の問題と、それがお客様に与える影響、および修正にかかる工数を文書化してきました。私は、現在のシステムが壊れているという主張をすることができます. 何らかの修正を推奨するのに十分な知識がありません。