プロパティファイルを管理するアプローチプロダクション環境で

Question

私はプロジェクト全体で共有されているプロパティファイルを管理する最良の方法について考えています。アプリケーション1、アプリケーション2 Application3とApplication4 - - 私たちは、プロパティファイル

1. File1.propertyの下に持って

   を考えてみましょう同じボックス上で展開されているすべてのアプリケーション -

   たちは四つのアプリケーションを持って考えてみましょアプリケーション1で使用、Application2 Application3 and Application4
2. File2.property - Application1、Application2で使用
3. File3.property - アプリケーション2 Application3
4. File4.propertyに使用 - 、Application1のに使用Application4を
5. File5.propertyは - Application3
6. File6.propertyで使用 -

Application4に使用します

今後、プロパティファイルの数が増加する可能性があります。

現在、私は以下検討しています1

アプローチに近づく - 個々のjarファイル内のすべての必要なプロパティファイルがバンドルされています。 短所 - 1：プロパティファイルが複数のプロジェクトで繰り返されています 2：すべてのプロパティファイルがすべてのプロジェクトでsynになっていることを確認する必要があります。

アプローチ2：別のプロジェクトにすべてのプロパティファイルを別々に作成します。このプロジェクトを設定プロジェクトとして展開します。
環境変数をこの場所に、Javaコードでこの場所のプロパティファイルを指定します。

いいですか？

Answer 1

あなたの質問から明らかにならないことの1つは、展開する提案が実際のプロダクションプロパティを含んでいるかどうか、またはアプリケーションがデプロイされたときに更新されるテンプレートだけであるかどうかです。

また、別の言い方をすれば、ソフトウェアの開発、テスト、制作の間に概念的な分離があるかどうか。あなたが行うと仮定すると、あなたが最も可能性が高いことがわかります。

• それぞれ「展開」は独自のプロパティセットが必要になります、
• 生産の展開可能性が最も高いのバージョン管理からバージョン管理が別個必要になりますアプリケーション
• 生産構成のライフサイクルは、アプリケーションのライフサイクルと異なる必要があります。

少なくとも、「開発」と「操作」が別個の責任である大規模な組織では、大規模なアプリケーションが通常処理される方法です。（dev-opsの世界では、 "dev"と "ops"のタスクが同じ人によって実行されたとしても、アプリケーションのライフサイクルと設定を分けることに価値があります）

ここには

• エンドユーザーのマシンにアプリケーションを展開する場合は、ある種類の優先管理フレームワークにそのプロパティを統合することをお勧めします。
• 状況によっては、クラス（またはXML）Javaプロパティファイルではなく、「.ini」ファイルを使用するほうがよい場合もあります。