Hamed Cédric SYLLA

🪧 Introduction

Qui n’a jamais utilisé spring.jpa.hibernate.ddl-auto=update pour faire évoluer le schéma de sa base de données dans un projet Spring Boot ?
C’est simple, rapide, mais… peut être dangereux.

Beaucoup de développeurs Java/Spring ne savent pas qu’il existe des outils pros comme Flyway pour gérer les évolutions de la base de données. Ces outils permettent de versionner chaque modification et d’assurer la stabilité du projet, même en équipe.

Dans cet article, je t’explique pourquoi il faut sortir de la « magie » Hibernate, comment fonctionne Flyway, et comment l’adopter simplement dans tes projets.

Cet article va t’expliquer :

• Les limites et les risques de ddl-auto
• Les différentes valeurs de la propriété Spring Boot
• Les avantages de Flyway, comparé à la génération automatique
• Un exemple concret d’intégration et de migration
• Les bonnes pratiques à adopter (et les pièges à éviter)

1. ⚠️ ddl-auto=update : la fausse bonne idée

Dans la majorité des tutos, on voit souvent ceci :

Mais sais-tu vraiment ce que cela fait ?
Petit tour d’horizon des valeurs possibles :

Valeur	Effet	Exemple d’utilisation
none	Aucune action. Ne touche pas à la base.	En production
create	Crée tout le schéma à chaque démarrage (écrase tout).	Pour les tests jetables, jamais en prod
create-drop	Crée au démarrage, supprime à l’arrêt	Tests locaux
update	Synchronise les entités et le schéma (en théorie…)	Développement rapide, mais peut facilement présenter un DANGER
validate	Vérifie la conformité, ne modifie rien	Pour contrôler sans toucher à la base

Pourquoi “update” pose problème ?

• Ajout de nouveaux champs, mais gère mal les suppressions, renommages, types modifiés
• Impossible de prévoir ce qui va vraiment se passer (surtout sur une base déjà peuplée et si on travaille en équipe)
• Aucun historique ni possibilité de rollback
• Collaboration compliquée : si deux devs font évoluer le schéma, gare aux surprises !
• En prod, tu risques de perdre des données ou de casser ton application sans retour arrière

⚠️ ddl-auto=update est pratique pour un prototype ou un POC, mais à bannir dès que le projet devient sérieux !

2. 🚦Pourquoi Flyway ? Le contrôle, tout simplement

Flyway, c’est un outil de migration de base de données simple et puissant qui t’aide à :

• Versionner chaque modification du schéma (fini les « je ne sais plus ce qui a été modifié »)
• Écrire des scripts SQL explicites, versionnés, stockés dans ton repo Git
• Appliquer les modifications dans l’ordre et traçable
• Revenir en arrière si besoin (dans la limite des scripts écrits)
• Travailler en équipe sans se marcher sur les pieds

Le principe ?

Chaque migration est un fichier SQL versionné (V1__init.sql, V2__add_user_table.sql, etc.).
Flyway garde en base un historique de ce qui a déjà été appliqué. À chaque démarrage, il applique seulement les nouveaux scripts.

3. 👨‍💻 Intégrer Flyway dans un projet Spring Boot

Étape 1 – Ajouter la dépendance Flyway

Avec Maven :

Étape 2 – Le dossier de migration

Par défaut, les scripts de migration doivent être placés dans le dossier src/main/resources/db/migration.
Ce répertoire est utilisé automatiquement par Flyway, mais tu peux le modifier à ta convenance via la propriété spring.flyway.locations dans ton application.properties.

Étape 3 – Écrire les scripts SQL

• Les scripts sont nommés ainsi : V1__init.sql, V2__add_column.sql, etc.
• Ils sont exécutés dans l’ordre des versions (V1, V2, etc. indique l’ordre d’exécution)

Exemple

Étape 4 – Configurer Flyway (optionnel, Spring le fait pour toi)

Tu peux, si besoin, ajuster le comportement de Flyway dans le fichier application.properties.
Par défaut, la configuration fonctionne sans rien changer, mais sache que presque tout est personnalisable selon tes besoins : chemin des migrations, nom du schéma, activation/désactivation, etc.

Au démarrage, Flyway vérifie la base, voit quelles migrations manquent, et les applique.

4. 🛡️ Bonnes pratiques et conseils

• Toujours désactiver ddl-auto en production (none ou validate)
• Versionne tes scripts SQL
• Ne mélange pas la génération automatique et Flyway : une seule source de vérité
• Teste chaque migration sur une base locale AVANT de déployer en prod
• Nomme tes fichiers de manière explicite : facile à relire, à comprendre et à auditer (cela facilite aussi le travail en équipe)

5. ⚡ Avantages concrets de Flyway

✔ Lisibilité : chaque migration est claire, traçable, et explicite
✔ Collaboration : chacun ajoute ses migrations, aucun risque de conflit caché
✔ Facilité de rollback (au moins sur les migrations simples, en réécrivant le script inverse)
✔ Aucune magie : c’est toi qui pilote !
✔ Adapté à toutes les bases SQL : PostgreSQL, MySQL, MariaDB, etc.

6. ❗️Limites à connaître

✖️ Pas de rollback automatique : Flyway ne revient pas en arrière tout seul. Si tu veux annuler une migration, tu dois écrire le script inverse manuellement.
✖️ Scripts à maintenir : plus il y a de migrations, plus il faut organiser et documenter ses fichiers pour garder la cohérence.
✖️ Migration destructive à manier avec précaution : les suppressions ou modifications de colonnes doivent être bien réfléchies pour ne pas perdre de données.
✖️ Pas adapté au NoSQL : Flyway gère uniquement les bases SQL.
✖️ Prise en main nécessaire : demande un petit effort de discipline par rapport à ddl-auto, surtout au début, le temps de prendre le pli.

Au final :
Même si Flyway impose un peu plus de rigueur et d’organisation qu’un simple ddl-auto=update, c’est ce qui en fait un outil pro et fiable ! Les limites sont largement compensées par la sécurité et la maîtrise des évolutions de ta base.

7. ❌ Ce qu’il ne faut PAS faire

• Laisser ddl-auto=update tourner en parallèle de Flyway
• Modifier la base « à la main » sans migration (oublie direct ce qui a été fait)
• Faire des scripts trop gros, ou peu explicites (“V15__global_changes.sql”)
• Oublier de tester sur une copie de la prod (avant d’exécuter en prod)

🧭 Conclusion

Avec Flyway, tu passes d’une gestion hasardeuse à une maîtrise totale de l’évolution de ta base de données.
Fini les surprises et les conflits liés à ddl-auto=update : chaque modification est tracée, testée, et versionnée.
Tu gagnes en transparence, en sécurité, et tu facilites le travail en équipe.

La base d’un projet solide commence par des migrations maîtrisées !

📚 Sources & lectures recommandées

• Database Migrations with Flyway
• How to Use Flyway for Database Migrations in Spring Boot Applications
• Simplifying Database Migrations in Spring Boot with Flyway: A Comprehensive Guide