Pourquoi les migrations de base de données nécessitent leur propre checklist
Un développeur pousse une modification qui supprime une colonne. Le pipeline de déploiement passe au vert. L'application se déploie avec succès. Mais la migration de base de données a déjà été exécutée, et cette colonne a disparu. Désormais, l'ancienne version de l'application, qui référence encore cette colonne, ne peut pas démarrer. L'équipe réalise qu'elle ne peut pas simplement revenir en arrière sur l'application sans également restaurer la base de données. Et restaurer la base de données signifie perdre toutes les données écrites après l'exécution de la migration.
Ce scénario se produit dans les équipes qui traitent les modifications de base de données de la même manière que les modifications de code applicatif. Le profil de risque est fondamentalement différent. Lorsque le code applicatif casse, vous pouvez redéployer la version précédente. Lorsqu'une migration de base de données casse, vous ne pouvez pas toujours annuler ce qui a été fait. Des données peuvent être perdues. Des contraintes peuvent être violées. Le schéma peut avoir changé de manière à rendre un simple rollback impossible sans une restauration complète à partir d'une sauvegarde.
C'est pourquoi les migrations de base de données ont besoin de leur propre template. Pas une checklist de déploiement générique. Quelque chose de spécifique à la nature des modifications de schéma, des transformations de données et des conséquences irréversibles de l'altération des données de production.
Le problème de traiter les migrations comme des déploiements de code
Les déploiements de code sont relativement sûrs car ils sont réversibles. Vous déployez la version 2, elle a un bug, vous déployez à nouveau la version 1. L'application redémarre avec l'ancien code et les utilisateurs continuent de travailler.
Les migrations de base de données ne fonctionnent pas de cette façon. Une fois qu'une migration est exécutée :
- Les colonnes supprimées ne peuvent pas être récupérées sans une restauration
- Les tables renommées cassent les requêtes qui utilisent encore l'ancien nom
- Les transformations de données qui suppriment ou modifient des valeurs ne peuvent pas être inversées en réexécutant la migration
- La création ou la suppression d'index peut modifier les performances des requêtes pendant des heures ou des jours
Le risque n'est pas seulement technique. Il est opérationnel. Une migration échouée peut mettre hors service l'ensemble de l'application, verrouiller des tables pendant de longues périodes et nécessiter une coordination entre les développeurs, les administrateurs de bases de données et les équipes d'exploitation pour récupérer.
Le template de migration de base de données en cinq étapes
Un bon template de migration n'est pas un script rigide. C'est une séquence de vérifications et d'actions qui réduit les risques de surprises. Chaque étape a un objectif clair, et sauter une étape augmente le risque.
Le diagramme suivant illustre le template en cinq étapes et les points de décision clés :
Étape 1 : Sauvegarder avant toute chose
Avant toute migration, la base de données doit être sauvegardée. Ce n'est pas une case à cocher pour la conformité. C'est le dernier filet de sécurité lorsque tout le reste échoue.
La sauvegarde doit être utilisable pour une restauration à l'état exact précédant la migration. Cela signifie :
Un script de migration réversible associe la modification forward à un rollback, clarifiant ainsi comment annuler si nécessaire :
-- Up : Ajouter une colonne avec une valeur par défaut
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP DEFAULT NULL;
-- Down : Supprimer la colonne (uniquement sûr si aucun code n'en dépend)
ALTER TABLE users DROP COLUMN last_login_at;
- Le fichier de sauvegarde doit être testé pour sa validité, pas seulement créé
- La procédure de restauration doit être documentée et pratiquée
- Pour les migrations à haut risque, une sauvegarde manuelle effectuée immédiatement avant la migration est préférable à une dépendance aux sauvegardes automatisées quotidiennes
Certaines équipes conservent des sauvegardes automatisées chaque nuit. C'est acceptable pour les opérations de routine. Mais pour une migration qui supprime une table ou modifie des millions de lignes, effectuez une sauvegarde juste avant le début de la migration. La sauvegarde doit être stockée dans un emplacement qui n'est pas affecté par la migration elle-même.
Étape 2 : Test à blanc sur un environnement réaliste
Un test à blanc signifie exécuter la migration sur un environnement non-production qui reflète la production aussi fidèlement que possible. L'objectif est de détecter les problèmes avant qu'ils n'atteignent la production.
Le mot clé est "réaliste". Exécuter la migration sur une base de données avec dix lignes ne vous apprend rien sur son comportement sur une base de données avec dix millions de lignes. Une migration qui se termine en deux secondes sur une base de données vide peut prendre vingt minutes sur des données de production. Pendant ces vingt minutes, les tables peuvent être verrouillées, les requêtes peuvent s'accumuler et l'application peut devenir indisponible.
Un environnement de test à blanc approprié doit avoir :
- Un schéma identique à la production
- Un volume de données proche de la production, ou au moins représentatif des plus grandes tables modifiées
- Un matériel ou des contraintes de ressources similaires, en particulier pour le CPU et les E/S
Exécutez la migration. Notez le temps que prend chaque instruction. Surveillez les conflits de verrouillage. Vérifiez les erreurs. Si le test à blanc révèle des problèmes, corrigez-les avant de toucher à la production.
Étape 3 : Exécuter la migration en production
C'est le moment critique. La migration doit être exécutée pendant les heures de faible trafic. Non pas parce que la migration elle-même va échouer, mais parce que l'impact de tout problème est moindre lorsque moins d'utilisateurs sont affectés.
Pendant l'exécution, surveillez activement :
- Combien de temps chaque instruction prend-elle pour se terminer ?
- Y a-t-il des verrous qui bloquent d'autres requêtes ?
- L'application répond-elle toujours aux requêtes, ou les connexions expirent-elles ?
- Les taux d'erreur augmentent-ils dans les journaux de l'application ?
Si la migration prend plus de temps que prévu, ne supposez pas qu'elle finira par se terminer. Ayez un plan pour l'interrompre ou la mettre en pause. Certaines migrations peuvent être divisées en lots plus petits. D'autres peuvent nécessiter de mettre temporairement l'application en mode maintenance.
Étape 4 : Vérifier le résultat
Ne vous fiez pas à un code de sortie vert. Une migration peut se terminer sans erreur et laisser la base de données dans un état cassé. La vérification signifie s'assurer que le schéma correspond aux attentes et que l'application peut se connecter et fonctionner.
Vérifiez en :
- Vérifiant que les nouvelles colonnes existent avec les types de données corrects
- Confirmant que les transformations de données ont produit les valeurs attendues
- Exécutant une requête de test qui utilise le schéma modifié
- Connectant l'application à la base de données et vérifiant les erreurs de connexion
Si la migration a ajouté des contraintes, vérifiez que les données existantes les satisfont. Si la migration a supprimé des contraintes, vérifiez que l'application fonctionne toujours correctement sans elles.
Étape 5 : Surveiller les effets à court terme
Les modifications de schéma ne cessent pas d'affecter le système une fois la migration terminée. Elles peuvent modifier les plans d'exécution des requêtes, changer l'utilisation des index et introduire de nouveaux modèles de verrouillage. Ces effets peuvent ne pas apparaître immédiatement.
Surveillez pendant les heures suivantes :
- Y a-t-il de nouvelles requêtes lentes dans la base de données ?
- Les taux d'erreur dans l'application sont-ils plus élevés qu'avant ?
- Y a-t-il des interblocages qui n'existaient pas auparavant ?
- L'application répond-elle dans les plages de latence normales ?
Utilisez les outils de surveillance existants. Ne vous fiez pas à la vérification manuelle des journaux. Configurez des alertes pour toute dégradation corrélée à l'heure de la migration.
Checklist pratique pour les migrations de base de données
| Étape | Action | Vérification |
|---|---|---|
| Sauvegarde | Effectuer une sauvegarde manuelle avant la migration | Tester que le fichier de sauvegarde est valide et restaurable |
| Test à blanc | Exécuter la migration sur un environnement de staging avec des données proches de la production | Comparer le temps d'exécution, vérifier les erreurs, noter la durée des verrous |
| Exécution | Exécuter la migration pendant le faible trafic | Surveiller la durée des instructions, les verrous, les erreurs applicatives |
| Vérification | Vérifier le schéma et les données après la migration | Confirmer les colonnes, les contraintes et la connectivité de l'application |
| Surveillance | Surveiller les changements de performances pendant 2 à 4 heures | Vérifier les requêtes lentes, les taux d'erreur, les interblocages |
L'essentiel à retenir
Les migrations de base de données ne sont pas des déploiements de code. Elles entraînent des conséquences irréversibles qui nécessitent une approche différente. Un template en cinq étapes - sauvegarde, test à blanc, exécution, vérification, surveillance - donne à votre équipe un moyen structuré de réduire les risques. Utilisez-le pour chaque migration, quelle que soit sa taille. La migration qui semble trop simple pour nécessiter une checklist est souvent celle qui cause le plus de dégâts.