Exécution automatique des migrations au démarrage

Le déclenchement automatique par Spring Boot : la simplicité intégrée

L'une des grandes forces de l'intégration de Flyway et Liquibase dans Spring Boot est l'exécution automatique des migrations lors du démarrage de l'application. Par défaut, si Spring Boot détecte la présence de la dépendance `spring-boot-starter-flyway` ou `spring-boot-starter-liquibase` sur le classpath et qu'une `DataSource` est configurée, il tentera d'appliquer les migrations de base de données nécessaires.

Ce comportement est activé grâce à l'auto-configuration de Spring Boot. Des classes de configuration spécifiques (par exemple, `FlywayAutoConfiguration` ou `LiquibaseAutoConfiguration`) s'activent conditionnellement. Elles créent et configurent les beans nécessaires (comme `Flyway` ou `SpringLiquibase`) et orchestrent l'exécution des migrations.

Cette exécution a lieu tôt dans le cycle de vie du démarrage de l'application, généralement avant l'initialisation complète des beans qui dépendent de la structure de la base de données, comme les beans de Spring Data JPA. Cela garantit que lorsque votre application commence à traiter des requêtes ou à interagir avec la base de données, le schéma est dans l'état attendu correspondant à la version actuelle du code.

Comment ça fonctionne sous le capot ?

Le mécanisme repose sur des beans spécifiques initialisés par l'auto-configuration. Pour Flyway, c'est souvent un bean `FlywayMigrationInitializer` qui dépend du bean `Flyway`. Pour Liquibase, c'est le bean `SpringLiquibase` lui-même.

Ces beans sont conçus pour exécuter la logique de migration lors de leur initialisation par le conteneur Spring. Cela se produit généralement parce qu'ils implémentent l'interface `InitializingBean` (dont la méthode `afterPropertiesSet()` est appelée après l'injection des dépendances) ou via une méthode annotée avec `@PostConstruct`. Spring Boot s'assure également, via des dépendances explicites (`@DependsOn`), que la `DataSource` est prête avant de tenter d'exécuter les migrations.

Lors de l'exécution, l'outil (Flyway ou Liquibase) se connecte à la base de données configurée. Il vérifie l'existence et le contenu de sa table de métadonnées (par exemple, `flyway_schema_history` pour Flyway ou `DATABASECHANGELOG` et `DATABASECHANGELOGLOCK` pour Liquibase) pour déterminer quelles migrations ont déjà été appliquées. Il compare ensuite cette liste avec les scripts de migration présents dans les emplacements configurés (par défaut `classpath:db/migration` pour Flyway, `classpath:db/changelog/db.changelog-master.xml` ou équivalent pour Liquibase). Finalement, il exécute les nouvelles migrations dans l'ordre défini (basé sur la convention de nommage pour Flyway ou l'ordre dans le changelog pour Liquibase).

Contrôler le comportement automatique

Bien que l'exécution automatique soit le comportement par défaut et souvent souhaité, vous pouvez le contrôler via les propriétés de configuration de Spring Boot. Pour désactiver complètement l'exécution automatique, vous pouvez définir les propriétés suivantes dans votre fichier `application.properties` ou `application.yml` :

# Pour Flyway
spring.flyway.enabled=false

# Pour Liquibase
spring.liquibase.enabled=false

Désactiver l'exécution automatique peut être utile dans certains scénarios, par exemple si vous préférez exécuter les migrations manuellement via un outil en ligne de commande ou un script séparé, ou dans des environnements de test spécifiques où vous gérez le schéma différemment.

D'autres propriétés permettent d'affiner le comportement sans le désactiver complètement. Par exemple, `spring.flyway.baseline-on-migrate=true` ou `spring.liquibase.baseline-on-migrate=true` sont utiles pour intégrer l'outil sur une base de données existante en marquant l'état actuel comme une 'baseline' sans essayer d'appliquer les anciennes migrations. Vous pouvez également spécifier explicitement les emplacements des scripts ou du fichier changelog maître :

# Exemple pour Flyway
spring.flyway.locations=classpath:db/custom_migration_scripts,filesystem:/opt/migrations

# Exemple pour Liquibase
spring.liquibase.change-log=classpath:db/changelog/my-master-changelog.yaml

L'activation ou la désactivation peut également être liée aux profils Spring. Vous pourriez avoir des migrations spécifiques pour les tests (`application-test.properties`) ou désactiver les migrations automatiques uniquement en production (`application-prod.properties`) si votre politique de déploiement l'exige.

Avantages et points d'attention de l'exécution automatique

L'avantage principal de l'exécution automatique est la garantie de cohérence entre la version du code de l'application et l'état du schéma de la base de données. Chaque fois que l'application démarre, elle s'assure que la base est à jour. Cela simplifie considérablement les processus de déploiement, en particulier dans les pipelines d'intégration et de déploiement continus (CI/CD), car l'étape de migration est intégrée au démarrage de l'application elle-même.

Cependant, il y a quelques points d'attention. Premièrement, l'exécution des migrations augmente le temps de démarrage de l'application, surtout s'il y a de nombreuses migrations à appliquer. Deuxièmement, si une migration échoue, par défaut, l'application ne démarrera pas. C'est généralement un comportement souhaitable car cela évite de démarrer l'application avec un schéma de base de données dans un état incohérent ou incorrect. Il est crucial de s'assurer que les scripts de migration sont corrects et testés.

Il est également essentiel que les scripts de migration soient écrits de manière idempotente lorsque c'est possible, ou du moins qu'ils puissent être gérés correctement par l'outil pour éviter les erreurs si une tentative d'exécution partielle a eu lieu. Les outils comme Flyway et Liquibase gèrent l'état dans leurs tables de métadonnées pour savoir quoi exécuter, mais une bonne conception des scripts reste importante. Enfin, prévoyez une stratégie en cas d'échec de migration en production (rollback manuel, correction et redéploiement, etc.).