Springでのプロジェクト構成

Springでのプロジェクト構成

1. 構成は環境固有である必要があります

構成は環境固有である必要があります-それは単なる現実です。 そうでない場合は、構成ではなく、値をコードにハードコーディングするだけです。

For a Spring application there are several solutions you can use –単純なソリューションから、非常に柔軟で非常に複雑な代替手段まで。

より一般的で直接的な解決策の1つは、properties filesfirst class property support provided by Springを柔軟に使用することです。

概念実証として、この記事では、特定の種類のプロパティであるデータベース構成について説明します。 1つのタイプのデータベース構成を実動用、別のタイプのテスト用、さらに別のタイプの開発環境を使用することは完全に理にかなっています。

2. 各環境の.propertiesファイル

ターゲットとする環境を定義することにより、概念実証を開始しましょう。

  • Dev

  • ステージング

  • 製造

次に、これらの環境ごとに1つずつ、3つのプロパティファイルを作成しましょう。

  • persistence-dev.properties

  • persistence-staging.properties

  • persistence-production.properties

通常のMavenアプリケーションでは、これらはsrc/main/resourcesに存在できますが、どこにいても、アプリケーションをデプロイするときにavailable on the classpathである必要があります。

重要な補足–having all properties files under version control makes configuration much more transparentおよび再現可能。 これは、ディスク上のどこかに設定を配置し、Springにそれらを単に指定するのとは反対です。

3. 春の構成

Springでは、環境に基づいて正しいファイルを含めます。




      

もちろん、Java構成でも同じことができます。

@PropertySource({ "classpath:persistence-${envTarget:dev}.properties" })

このアプローチにより、specific, focused purposesに対して複数の*.propertiesファイルを柔軟に使用できます。 たとえば、この例では、永続性のSpring構成は永続性プロパティをインポートします。これは完全に理にかなっています。 セキュリティ設定は、セキュリティ関連のプロパティなどをインポートします。

4. 各環境でのプロパティの設定

最後の展開可能な戦争will contain all properties files –永続性のために、persistence-.propertiesの3つのバリアント。 ファイルには実際には異なる名前が付けられているため、誤って間違ったファイルを含める恐れはありません。 *envTarget変数を設定し、複数の既存のバリアントから必要なインスタンスを選択します。

envTarget変数は、OS /環境で、またはJVMコマンドラインのパラメーターとして設定できます。

-DenvTarget=dev

5. テストとMaven

永続性を有効にする必要がある統合テストの場合– pom.xmlでenvTargetプロパティを設定するだけです。


   org.apache.maven.plugins
   maven-surefire-plugin
   
      
         h2_test
      
   

対応するpersistence-h2_test.propertiesファイルをsrc/test/resourcesに配置して、only be used for testingにし、実行時に戦争で不必要にインクルードおよびデプロイされないようにすることができます。

6. もっと遠く行く

必要に応じて、このソリューションに柔軟性を追加する方法がいくつかあります。

そのような方法の1つは、プロパティファイルのmore complex encoding for the namesを使用して、それらが使用される環境だけでなく、より多くの情報(永続性プロバイダーなど)も指定することです。 たとえば、次のタイプのプロパティを使用する場合があります:persistence-h2.propertiespersistence-mysql.properties、またはさらに具体的には:persistence-dev_h2.propertiespersistence-staging_mysql.propertiespersistence-production_amazonRDS.properties

このような命名規則の利点は、全体的なアプローチに何の変化もないのでjust a conventionであり、単に透明性です。 名前を見るだけで設定が何をするかがより明確になりました:

  • persistence-dev_h2.propertiesdev環境の永続性プロバイダーは、軽量のインメモリH2データベースです。

  • persistence-staging_mysql.propertiesstaging環境の永続性プロバイダーはMySQLインスタンスです

  • persistence-production_amazon_rds.propertieproduction環境の永続性プロバイダーはAmazon RDS

7. 結論

この記事では、Springで環境固有の構成を行うための柔軟なソリューションについて説明します。 プロファイルcan be found hereを使用する代替ソリューション。

ソリューションの実装はthe GitHub projectにあります。これはMavenベースのプロジェクトであるため、そのままインポートして実行するのは簡単です。