Fichiers de configuration spécifiques aux profils (application-{profile}.properties)

Le principe : un fichier par profil

L'une des fonctionnalités les plus pratiques du système de profils de Spring Boot est sa capacité à charger automatiquement des fichiers de configuration dédiés à des profils spécifiques. Cela permet de séparer physiquement les configurations de chaque environnement (développement, test, production, etc.) du fichier de configuration principal (application.properties ou application.yml) qui contient les valeurs par défaut ou communes.

La convention est simple et intuitive : pour un profil nommé monprofil, Spring Boot recherchera et chargera automatiquement (s'il existe) un fichier nommé application-monprofil.properties ou application-monprofil.yml. Ce mécanisme s'active dès qu'un ou plusieurs profils sont rendus actifs via la propriété spring.profiles.active ou d'autres moyens.

Convention de nommage et emplacement

La convention de nommage est stricte :

• Pour le format Properties : application-{nomDuProfil}.properties
• Pour le format YAML : application-{nomDuProfil}.yml (ou .yaml)

Où {nomDuProfil} est le nom exact du profil que vous avez défini (par exemple, `dev`, `prod`, `test`, `cloud`, `docker`, etc.). Les noms de profils sont sensibles à la casse sur certains systèmes de fichiers, il est donc préférable d'utiliser une casse cohérente (généralement tout en minuscules).

Ces fichiers spécifiques aux profils sont généralement placés au même endroit que le fichier de configuration principal, c'est-à-dire à la racine du répertoire src/main/resources dans la structure de votre projet Maven ou Gradle.

Exemple de structure de projet :

src/
└── main/
    └── resources/
        ├── application.yml          # Config commune / par défaut
        ├── application-dev.yml      # Config pour le profil 'dev'
        ├── application-prod.yml     # Config pour le profil 'prod'
        └── application-test.yml     # Config pour le profil 'test'

Surcharge des propriétés : la priorité des profils

Le point crucial à comprendre est que les propriétés définies dans un fichier spécifique à un profil actif prennent le pas sur (surchargent) les propriétés identiques définies dans le fichier principal application.properties ou application.yml. Spring Boot charge les fichiers de configuration dans un ordre précis, et les fichiers spécifiques aux profils sont chargés après le fichier principal, leur donnant ainsi une priorité plus élevée.

Reprenons un exemple :

application.yml (principal) :

server:
  port: 8080
app:
  base-url: http://default.example.com
  feature-x:
    enabled: false

application-prod.yml (spécifique au profil `prod`) :

server:
  port: 80 # Surcharge le port par défaut
app:
  base-url: https://prod.example.com # Surcharge l'URL de base
# app.feature-x.enabled n'est pas redéfini ici

Si l'application est lancée avec --spring.profiles.active=prod :

• La propriété server.port aura la valeur 80 (celle de application-prod.yml).
• La propriété app.base-url aura la valeur https://prod.example.com (celle de application-prod.yml).
• La propriété app.feature-x.enabled aura la valeur false (celle de application.yml, car elle n'a pas été surchargée dans le fichier de profil).

Ce mécanisme de surcharge permet de définir des valeurs par défaut raisonnables dans le fichier principal et de ne spécifier que les différences nécessaires dans les fichiers spécifiques à chaque environnement. Cela rend la configuration plus concise et plus facile à gérer.

Gestion de plusieurs profils actifs

Il est possible d'activer plusieurs profils simultanément, par exemple spring.profiles.active=dev,mysql. Dans ce cas, Spring Boot essaiera de charger les fichiers correspondants pour chaque profil actif (application-dev.properties et application-mysql.properties, en plus de application.properties).

La question se pose alors : que se passe-t-il si une même propriété est définie dans plusieurs fichiers de profils actifs ? La règle est simple : le dernier profil listé dans la propriété spring.profiles.active l'emporte.

Exemple :

spring.profiles.active=dev,override

application-dev.properties :

my.property=Valeur de DEV

application-override.properties :

my.property=Valeur de OVERRIDE

Dans ce cas, la valeur finale de my.property sera "Valeur de OVERRIDE", car `override` est le dernier profil listé dans spring.profiles.active.

Avantages de l'approche par fichiers dédiés

Utiliser des fichiers de configuration spécifiques aux profils offre plusieurs avantages :

• Clarté et Organisation : Sépare nettement les configurations des différents environnements, rendant le projet plus facile à comprendre et à naviguer.
• Sécurité : Permet de ne pas inclure de données sensibles de production (mots de passe, clés API) dans le code source principal ou dans les configurations de développement. Le fichier application-prod.properties peut être géré séparément et déployé de manière sécurisée.
• Maintenance Simplifiée : Les modifications spécifiques à un environnement sont localisées dans un seul fichier, réduisant le risque d'affecter accidentellement d'autres environnements.
• Lisibilité : Les fichiers spécifiques aux profils ne contiennent que les différences par rapport à la configuration par défaut, ce qui les rend généralement plus courts et plus ciblés.

En conclusion, l'utilisation des fichiers application-{profile}.properties (ou .yml) est une pratique fondamentale et hautement recommandée pour gérer efficacement la configuration dans les applications Spring Boot destinées à être déployées dans plusieurs environnements. C'est un mécanisme puissant qui favorise la clarté, la sécurité et la maintenabilité de votre configuration.