TOC

Configuration du projet avec Spring

Configuration du projet avec Spring

Table des matières

1. La configuration doit être spécifique à l'environnement

La configuration doit être spécifique à l’environnement - ce n’est qu’une réalité. Si ce n’était pas le cas, ce ne serait pas la configuration et nous coderions simplement les valeurs en dur dans le code.

For a Spring application there are several solutions you can use - des solutions simples jusqu'aux alternatives ultra-flexibles et très complexes.

Une des solutions les plus courantes et les plus simples est une utilisation flexible deproperties files et desfirst class property support provided by Spring.

À titre de preuve de concept, aux fins de cet article, nous allons examiner un type spécifique de propriété: la configuration de la base de données. Il est parfaitement logique d'utiliser un type de configuration de base de données pour la production, un autre pour les tests et un autre pour les environnements de développement.

2. Les fichiers.properties pour chaque environnement

Commençons notre Proof of Concept - en définissant les environnements que nous voulons cibler:

  • Dev

  • Mise en scène

  • Production

Ensuite, créons 3 fichiers de propriétés - un pour chacun de ces environnements:

  • persistence-dev.properties

  • persistence-staging.properties

  • persistence-production.properties

Dans une application Maven typique, ceux-ci peuvent résider danssrc/main/resources, mais où qu'ils soient, ils devront êtreavailable on the classpath lorsque l'application est déployée.

Un sidenote important -having all properties files under version control makes configuration much more transparent et reproductible. Cela va à l’encontre du fait d’avoir les configurations sur le disque quelque part et de simplement pointer Spring vers elles.

3. La configuration du ressort

Au printemps, nous inclurons le bon fichier en fonction de l'environnement:

La même chose peut évidemment être faite avec la configuration Java: 

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

Cette approche permet la flexibilité d'avoir plusieurs fichiers*.properties pourspecific, focused purposes. Par exemple - dans notre cas, la persistance Spring config importe les propriétés de persistance - ce qui est parfaitement logique. La configuration de sécurité importerait des propriétés liées à la sécurité, etc.

4. Définition de la propriété dans chaque environnement

La guerre finale déployablewill contain all properties files - pour la persistance, les trois variantes depersistence-.properties. Étant donné que les fichiers portent en fait un nom différent, il n’ya aucune crainte d’inclure accidentellement le mauvais. Nous allons définir * la variableenvTarget et sélectionner ainsi l'instance que nous voulons parmi les multiples variantes existantes.

La variableenvTarget peut être définie dans le système d'exploitation / l'environnement ou en tant que paramètre de la ligne de commande JVM: 

-DenvTarget=dev

5. Test et Maven

Pour les tests d'intégration qui nécessitent l'activation de la persistance, nous allons simplement définir la propriétéenvTarget dans le pom.xml: 


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

Le fichierpersistence-h2_test.properties correspondant peut être placé danssrc/test/resources afin qu'il soitonly be used for testing et ne soit pas inutilement inclus et déployé avec la guerre lors de l'exécution.

6. Aller plus loin

Il existe plusieurs façons de créer une flexibilité supplémentaire dans cette solution si nécessaire.

Un de ces moyens consiste à utiliser unmore complex encoding for the names des fichiers de propriétés, en spécifiant non seulement l'environnement dans lequel ils doivent être utilisés, mais également plus d'informations (comme le fournisseur de persistance). Par exemple, nous pourrions utiliser les types de propriétés suivants:persistence-h2.properties,persistence-mysql.properties ou, encore plus spécifique:persistence-dev_h2.properties,persistence-staging_mysql.properties,persistence-production_amazonRDS.properties.

L'avantage d'une telle convention de dénomination - et c'estjust a convention car rien ne change dans l'approche globale - est simplement la transparence. Il devient maintenant beaucoup plus clair ce que la configuration ne fait qu'en regardant les noms:

  • persistence-dev_h2.properties: le fournisseur de persistance de l'environnementdev est une base de données H2 légère en mémoire

  • persistence-staging_mysql.properties: le fournisseur de persistance de l'environnementstaging est une instance MySQL

  • persistence-production_amazon_rds.propertie: le fournisseur de persistance de l'environnementproduction est Amazon RDS

7. Conclusion

Cet article décrit une solution flexible permettant d'effectuer une configuration spécifique à l'environnement dans Spring. Une solution alternative utilisant les profilscan be found here.

L'implémentation de la solution peut être trouvée dansthe GitHub project - il s'agit d'un projet basé sur Maven, il devrait donc être facile à importer et à exécuter tel quel.

Related