Une migration de base ne se joue pas deux fois
Il existe deux façons de faire évoluer le schéma d'une base de données en production. La première consiste à se connecter et à taper la commande. La seconde à écrire un fichier numéroté, à le rejouer d'abord en recette, puis à le laisser s'appliquer tout seul au déploiement.
La différence ne se voit pas le premier jour. Elle se voit le jour où quelque chose casse.
Ce que coûte la première méthode
Une commande tapée à la main n'existe nulle part ensuite. Six mois plus tard, personne ne sait dans quel ordre les colonnes ont été ajoutées, ni si la base de recette a reçu les mêmes. Elle a probablement divergé, et l'écart ne se manifestera qu'au pire moment : quand un correctif validé en recette se comportera autrement en production.
Restaurer une sauvegarde devient également un pari. La sauvegarde porte un schéma daté ; l'application, elle, attend celui d'aujourd'hui. Rien ne dit quelles commandes rejouer pour combler l'écart, ni dans quel ordre.
Ce que fait la seconde
Chaque évolution est un fichier : V1, V2, V3, dans le dépôt, à côté du
code qui en dépend. L'outil de migration tient dans la base une table de ce
qui a déjà été appliqué, et n'applique que le reste.
Trois propriétés en découlent, et ce sont elles qui comptent :
Une base vide devient une base à jour en rejouant la suite depuis le début. C'est ce qui rend une nouvelle installation reproductible, et une machine de développement jetable.
Recette et production convergent par construction : elles reçoivent les mêmes fichiers dans le même ordre.
Le schéma est relu comme du code. Une migration passe par la même vérification qu'une modification de code, avant d'atteindre les données réelles.
Les règles qui font que ça tient
Un fichier appliqué ne se modifie plus. Jamais. L'outil retient l'empreinte de chaque fichier ; en modifier un déjà appliqué fait échouer le démarrage — et c'est un service qu'il rend, car la production, elle, a déjà la version d'avant. La correction se fait dans un fichier suivant.
Les données de référence sont aussi des migrations. Les taux de TVA, les libellés de statuts, le compte administrateur initial : tout ce sans quoi l'application ne démarre pas mérite un fichier numéroté, pas une insertion manuelle qu'on refera de mémoire.
Une migration destructrice se découpe. Renommer une colonne en une seule opération casse l'application déployée pendant la seconde qui sépare la migration du redémarrage. Ajouter la nouvelle colonne, écrire dans les deux, migrer les données, puis supprimer l'ancienne au déploiement suivant : quatre étapes, aucune interruption.
Le vrai test
Une chaîne de migrations se juge à une question simple : à partir d'une base vide, la suite complète se rejoue-t-elle sans erreur ?
Si la réponse est non — parce qu'un fichier ancien suppose une donnée insérée à la main un jour, ou parce que deux migrations se contredisent — alors la reproductibilité est déjà perdue, et personne ne le sait encore.
C'est un contrôle qui coûte une minute et qui a sa place dans les tests.