Gestion des migrations de schéma avec Flyway/Liquibase

1. Le problème : Pourquoi ddl-auto n'est pas une solution viable

Vous avez peut-être déjà rencontré la propriété Spring spring.jpa.hibernate.ddl-auto. La configurer sur update peut sembler pratique en développement : Hibernate compare vos entités JPA au schéma de la base et tente d'appliquer les modifications (créer des tables, ajouter des colonnes).

Cependant, cette approche est extrêmement dangereuse et inadaptée à la production pour plusieurs raisons :

• Manque de contrôle : Vous ne maîtrisez pas le SQL qui est exécuté.
• Risque de perte de données : Une simple modification, comme le renommage d'un champ dans une entité, peut amener Hibernate à supprimer l'ancienne colonne et en créer une nouvelle, effaçant ainsi toutes les données qu'elle contenait.
• Non versionné : Il n'y a aucun historique des changements. Vous ne pouvez pas facilement recréer un état précis de la base de données.
• Problèmes de concurrence : Dans un environnement avec plusieurs instances de l'application (ce qui est courant), chaque instance pourrait essayer de modifier le schéma en même temps, menant au chaos.

La vidéo suivante illustre parfaitement les limites de cette approche.

La conclusion est claire : pour un projet professionnel, nous avons besoin d'une solution robuste et explicite.

2. Flyway : La migration de base de données en toute simplicité

Flyway est l'un des outils de migration les plus populaires dans l'écosystème Java. Sa philosophie est simple et SQL-first.

Le fonctionnement de Flyway repose sur trois piliers :

1. Des scripts de migration SQL : Vous écrivez des fichiers SQL standards pour chaque changement de schéma.
2. Une convention de nommage : Les fichiers doivent suivre le format V<VERSION>__Description.sql (par exemple, V1__Create_user_table.sql). La version permet à Flyway de les exécuter dans le bon ordre.
3. Une table d'historique : Flyway crée et maintient une table dans votre base de données (par défaut flyway_schema_history) pour savoir exactement quels scripts ont déjà été appliqués.

Au démarrage de l'application, Flyway scanne les scripts, les compare à sa table d'historique et applique uniquement les nouvelles migrations.

Mise en pratique avec Flyway et Spring Boot

L'intégration de Flyway avec Spring Boot est remarquablement simple grâce à l'auto-configuration.

Pour résumer le processus à suivre dans votre projet :

1. Ajoutez la dépendance Flyway à votre pom.xml.

   <dependency>
       <groupId>org.flywaydb</groupId>
       <artifactId>flyway-core</artifactId>
   </dependency>
   <!-- Si vous utilisez PostgreSQL -->
   <dependency>
       <groupId>org.flywaydb</groupId>
       <artifactId>flyway-database-postgresql</artifactId>
   </dependency>
   

2. Désactivez la gestion du schéma par Hibernate dans application.properties. C'est maintenant la responsabilité de Flyway.

   spring.jpa.hibernate.ddl-auto=none
   

   Spring Boot détectera Flyway sur le classpath et l'activera automatiquement.

3. Créez vos scripts de migration dans le répertoire src/main/resources/db/migration/.

   • V1__create_tables.sql :

     CREATE TABLE my_users (
         id BIGSERIAL PRIMARY KEY,
         username VARCHAR(255) NOT NULL UNIQUE,
         password VARCHAR(255) NOT NULL
     );
     

   • V2__add_email_to_my_users.sql :

     ALTER TABLE my_users
     ADD COLUMN email VARCHAR(255);
     
     UPDATE my_users SET email = 'default@example.com' WHERE email IS NULL;
     
     ALTER TABLE my_users
     ALTER COLUMN email SET NOT NULL;
     

Au prochain démarrage, votre base de données sera migrée de manière sûre et versionnée.

3. Liquibase : L'alternative plus complète

Liquibase est l'autre acteur majeur. Il est plus ancien, plus puissant et aussi un peu plus complexe que Flyway. Il est particulièrement apprécié dans les grands projets d'entreprise.

Voici les principales différences :

• Formats multiples : Alors que Flyway est centré sur le SQL, Liquibase vous permet d'écrire vos migrations en XML, YAML, ou JSON, en plus du SQL. Cela permet de définir des changements de manière abstraite et agnostique à la base de données (par ex., <addColumn> au lieu de ALTER TABLE ...).
• Rollbacks : Liquibase a un support intégré pour les "rollbacks", c'est-à-dire la capacité d'annuler une migration. C'est une fonctionnalité puissante mais qui peut être complexe à maintenir.
• Concepts : Liquibase utilise des changeLogs (fichiers) qui contiennent des changeSets (unités de changement atomiques identifiées par un auteur et un ID).

Pour vous donner une idée de sa structure, la vidéo suivante propose une excellente introduction aux concepts de Liquibase.

Pour un complément en français, cet article compare les deux outils et détaille le fonctionnement de Liquibase.

Quel outil choisir ? Pour la plupart des projets, surtout ceux qui débutent, Flyway est souvent suffisant, plus simple et favorise des pratiques saines (SQL explicite, approche "roll-forward"). Liquibase est un excellent choix pour les projets nécessitant un support pour plusieurs types de bases de données ou des stratégies de rollback complexes.

4. Bonnes pratiques professionnelles

Utiliser l'outil ne suffit pas. Pour garantir des déploiements fiables, il est crucial d'adopter des bonnes pratiques.

Voici un résumé des règles d'or :

1. Une migration versionnée est immuable : Une fois qu'un script (ex: V2_...) a été appliqué, ne le modifiez plus jamais. Si une erreur est trouvée, créez un nouveau script (V3_...) pour la corriger. C'est le principe du roll-forward.
2. Faites des changements petits et atomiques : Préférez trois petites migrations à une seule migration géante.
3. Testez vos migrations : Intégrez l'exécution des migrations dans votre pipeline CI sur une base de données de test propre.
4. Interdisez les modifications manuelles : Le seul moyen de modifier le schéma doit être via l'outil de migration. Toute modification manuelle créera une "dérive" du schéma et fera échouer les déploiements futurs.
5. Révisez le code des migrations : Les scripts de migration sont du code. Ils doivent être soumis au même processus de revue que le reste de votre application.

Conclusion

Vous savez désormais comment gérer l'évolution du schéma de votre base de données de manière professionnelle, une compétence non négociable dans le développement moderne.

Points clés à retenir :

• L'utilisation de spring.jpa.hibernate.ddl-auto est à proscrire en production.
• Les outils comme Flyway et Liquibase permettent de versionner les changements de base de données, en traitant les scripts de migration comme du code.
• Flyway est simple, basé sur des scripts SQL nommés de manière séquentielle (V1__..., V2__...).
• Liquibase est plus flexible (XML, YAML, SQL) et supporte nativement les rollbacks, au prix d'une complexité accrue.
• Au démarrage, l'outil compare les scripts du projet avec sa table d'historique et n'applique que les nouveaux changements.
• Le respect des bonnes pratiques (immutabilité des scripts, tests, interdiction des modifications manuelles) est aussi important que le choix de l'outil.

Prochaine étape :
Maintenant que notre application est "autonome" – elle contient son code, ses dépendances, et sait comment mettre à jour la base de données dont elle a besoin – nous sommes prêts à la packager pour le déploiement. Dans la prochaine leçon, nous allons enfin aborder le sujet promis : écrire un Dockerfile optimisé pour conteneuriser notre application Spring Boot. Nous créerons une image portable, prête à être déployée n'importe où.