現在、開発、テスト、および制作のような異なる環境でSpringアプリケーションをデプロイしています。環境ごとに異なるプロパティファイルdev-app.properties、test-app.properties、prod-app.propertiesがあります。 データソースプロパティのような異なるトークンは、PropertyPlaceholderConfigurerを使用してロードされます。 配備中に、適切なプロパティファイルがクラスパスに追加され、アプリケーションが正常に配備されました。 私はこの仕事のために春のプロファイルを使用できますか？もしそうなら、どのような利点がありますか？デプロイ中のSpringプロファイルの利点
おかげ
このケースでは、春のプロファイルは最適なオプションではありません。これらの2つのオプションをお勧めします。 1. Mavenプロファイルまたは 2.ランタイムスプリングプロパティファイル。
春のプロファイルとは何かを説明しましょう。 環境/プロファイルに基づいて異なるBeanが必要な場合は、春のプロファイルが使用されます。例として、devとlocalに異なるキャッシュマネージャーBeanを使用したいとします。これを参照してください https://www.mkyong.com/spring/spring-profiles-example/ 簡単のため、クラスAはキャッシュマネージャータイプ1です。クラスBはキャッシュマネージャータイプ2です。また、キャッシュマネージャーをautowiresする第3クラスCのBeanがあります。クラスAにプロファイルDevを付ける。そして、ローカルのプロフィールBを持つクラスB。だから、私がspring.active.profile = Devでアプリケーションを起動すると、クラスAのBeanがクラスCのBeanに自動的に注入されます。そして今、spring.active.profile = Localでアプリケーションを起動すると、クラスBのBeanクラスCのBeanに注入されます。
ここでMavenプロファイルについて話しましょう。このソリューションでは、すべての環境のプロパティがリソースフォルダの下にあります。それぞれが独自の名前を持っています。次に、pom.xmlでどのenvがどのファイルを取るかを定義します。ビルドを呼び出すと、環境を指定するだけで、それらのプロパティが注入されます。ここをクリックしてください https://maven.apache.org/guides/mini/guide-building-for-different-environments.html
最後に、プロパティファイルのランタイムスプリングプロパティが私のお気に入りのソリューションです。この1つでは、プロジェクト内にプロパティファイルはありません。その春のブートアプリケーション、ちょうどmavenのビルドを行います。アプリケーションを起動するときに、このプロパティをvm引数 -Dspring.config.location = file：c：/application.properties として指定します。そのファイルからプロパティを選択し、アプリケーションを起動します。 これを参照してくださいhttp://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html これに関する最も良いことは、すべての環境で同じビルドが動作することです。 jar/warが作成され、devでテストされたら、同じjarファイルを再構築することなく、さらに環境を改善することができます。これにより、再構築プロセス中に導入されたエラーを減らすことができます。明らかに、その地域でアプリを起動するときに適切なプロパティファイルが正しいディレクトリにあることを確認する必要があります。
このようなものに対してmavenプロファイルを使用することについて私は正直に同意しません。第1に、プロダクションに展開するために新しい成果物を生成する必要があるため、アーティファクト（いくつかの設定では立法要件）を証明することが不可能になります。第2に、間違ったビルドプロファイルを持つアーチファクトを展開するリスクは、プロファイルがアーチファクト名から明らかではないため、自明ではありません。ビルド・プロファイルを使用してビルド機能（コード・カバレッジ・レポート、静的分析、ドキュメント生成など）を有効にすることをお勧めします。ちょうど私の$ 0.02 – Taylor
必ずMavenプロファイルを使用するということは、あらゆる環境に合わせて新しいビルドを作成することを意味します。したがって、私は私の個人的な好みが、同じビルド全体を利用する外部化されたスプリングプロパティファイルを使用していると述べました。それにもかかわらず、私はmavenプロファイルを使用して多くの成功したプロジェクトを見てきました。 – user2254601
合意し、ちょうど警告を呼び出すことを望んでいた。 – Taylor
それは基本的に使用すると、1つの概念の下で（長所と短所を持っている）あなたに展開中のプロファイルとグループこれらを維持することができます。例えば。あなたは持っている可能性があります
/properties/prod/db.properties
/properties/prod/filestore.properties
/properties/test/db.properties
/properties/test/filestore.properties
これらを切り替えると、複数のプロパティファイルを管理するのではなく、プロファイルを変更することになります。
環境に基づいて異なる構成が必要な場合は、propertyplaceholderを使用するだけで十分であり、スプリングプロファイルを使用する必要がある場合。 例 -
<!--Profile for the Dev Environment-->
<beans profile="dev">
<bean id="dataSource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
<!--Profile for the Prod Environment-->
<beans profile="prod">
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
プロフィールはその後、私はあなたに何があるか分からないSpring Profiles
リファ
のprodのenv
開発のenv AS-ロードすることができますプロパティを使用できますが、おそらくプロファイルを使用してdiffを反映させることができますあなたが特定の環境のために特定のBeanを持つことができるという利点があります（そして、それはプロパティでより難しいです）。 –