0

Spring Profiles について質問があります。環境ごとに別のアーティファクトが必要になるため、maven プロファイルを使用しない理由を理解しています。それ以来です。Spring Profile を使用するようにコードを変更しましたが、Spring Profiles の問題は、サーバー上に環境ごとに database.property ファイルが必要なことです。私はこのセットアップを持っています。誰もが何百回も見たのと同じセットアップです。

src
- main
- resources
   -conf
     myapp.properties
   -env
      dev.db.properties
      test.db.properties
      prod.db.properties

このセットアップで私が考える問題は、各サーバーがenvディレクトリにすべてのファイルを持っていることです（つまり、devはそのサーバーにprod.db.propertiesとtest.db.propertiesファイルを持っています）。プロファイルを使用せずに、maven のビルド中に必要なファイルのみをコピーする方法はありますか? 私は方法を理解することができませんでした。その場合、これは maven プロファイルを使用する理由のように思えます。私は何かを逃したかもしれません。どんな考えでも大歓迎です。

4

2 に答える 2

0

最初に、アプリケーションが実際に何であるかを指摘する必要があります。「異なる環境でアプリケーションを実行している」か、「独自の環境で異なるアプリケーション」を実行しているか。これは、わずかに異なる 2 つの概念です。

  • 異なる環境でアプリケーションを実行している場合は、すべてのプロパティ ファイルを jar に入れることをお勧めします。新しい SUV を購入することを想像してみてください。最初にテストコースで運転し、次に通常の高速道路を走行した後、オフロードに進み、最終的にそのオフロード機能を楽しむことができます. さまざまな環境で、すべての機能と運転特性を備えた同じ車を常に使用します。それぞれの環境で、車はその挙動と運転特性を適応させます。1 つのアプリケーションを使用して異なる環境を駆動する場合は、最初のアプローチを使用して、すべての環境特性を 1 つの jar に構築します。
  • 一方で、異なる環境でわずかに異なる車を使用することもできます。したがって、さまざまな環境に合わせて独自の特別な運転特性を備えたさまざまな車が必要な場合、たとえば 4WD や、夜間に運転するために特別なフラッド ライトが必要な場合は、2 番目のアプローチを取る必要があります。アプリケーションに戻る: さまざまな実稼働環境でまったく異なる特性を持つさまざまなアプリケーションが必要な場合は、実際に必要なプロパティのみを使用して各アプリケーションを構築することをお勧めします。

最後に、2 つのアプローチをマージすることもできます。

  • my-fun-application-foo.jar は、テスト、統合、および実稼働環境のプロパティを持つ顧客 foo 用です。
  • my-fun-application-2047.jar for customer 2047 with test, pre-integration, integration, pre-production and production environment.

これで、さまざまなフレーバーのアプリケーションを構築するためにプロファイルを使用してはならない理由も理解できるはずです。

于 2014-01-30T08:48:56.713 に答える