Historique de la question
Travailler sur de grands projets nécessite que la structure de la base de données évolue parallèlement au code de l'application. Sans contrôle de version programmatique des modifications de schéma (ajouts, suppressions et modifications de tables, index, clés), l'équipe perd rapidement la synchronisation, le risque de perte des modifications augmente, les échecs de migration deviennent plus fréquents et le retour en arrière ou la reproduction de bogues se complique.
Problème
L'approche traditionnelle — modifier manuellement la base de données via des scripts SQL — conduit à un ordre d'exécution des modifications implicite, à des difficultés de retour en arrière, et à des incohérences de version entre les environnements (dev, test, prod). Sans un outil commun pour stocker les migrations, il est difficile de comprendre qui, quand et pourquoi a modifié le schéma.
Solution
Pour cette tâche, des systèmes de migration de schéma et des pratiques de versioning de base de données sont utilisés. L'application d'outils (par exemple, Liquibase, Flyway, Alembic pour différents SGBD) permet de stocker les scripts SQL de modifications de schéma directement dans le système de contrôle de version (git), de générer une séquence stricte de migrations et d'automatiser les mises à jour de schéma sur tous les environnements.
Exemple de code (migration via Flyway):
-- V002__add_column_email.sql ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;
Intégration de Flyway (par exemple, pour Java):
Flyway.configure().dataSource(url, user, pass).load().migrate();
Caractéristiques clés :
Peut-on stocker l'"état initial" du schéma (snapshot) au lieu de migrations ? À première vue, un « dump » de l'ensemble du schéma semble plus simple que les migrations. Mais cela entraînera des problèmes de retour en arrière, de restauration d'états intermédiaires et de fusion de modifications provenant de différentes branches. Les migrations permettent d'appliquer uniquement les nouvelles modifications de manière séquentielle et dans le bon ordre.
Doit-on synchroniser manuellement les migrations entre différents environnements ? Non, les systèmes modernes respectent le versioning et n'appliquent automatiquement que les migrations qui n'ont pas encore été effectuées dans la base. L'important n'est pas la synchronisation manuelle, mais l'application automatisée des migrations lors du déploiement.
Suffit-il de disposer uniquement de scripts SQL de migrations ou faut-il stocker autre chose ? Une bonne pratique consiste à stocker, en plus des scripts SQL, leur description (objectif, auteur, date), ainsi que des tests validateurs sur les nouvelles modifications structurelles, afin d'automatiser le contrôle de qualité des migrations.
Le projet utilisait des dumps de schéma ordinaires et une application "manuelle" des modifications par les développeurs. Après le lancement d'une mise à jour, le client a remarqué que certaines des nouvelles colonnes n'étaient pas apparues dans la base de production, et que certains index se doublent après chaque tentative de mise à jour du schéma.
Avantages :
Rapide pour de très petits projets.
Inconvénients :
Difficultés de maintenance ; on ne peut pas comprendre ce qui a vraiment été modifié et par qui ; impossibilité de retour en arrière ; différents environnements s'éloignent.
L'équipe a intégré Flyway, tous les changements structurels se font par des migrations avec un code de revue, le retour à n'importe quelle version prenait quelques minutes, et il était facile d'effectuer des tests et des contrôles sur tous les environnements.
Avantages :
Automatisation, historique, faible probabilité de bogues au moment du déploiement.
Inconvénients :
Nécessité de documenter un peu plus longuement chaque changement de structure.