Cet article est tire de l'article original "Database Schema Migrations in Production: Patterns and Pitfalls" sur le site pganalyze.com/blog
Migrer un schema de base de donnees en production est l'une des operations les plus delicates du cycle de developpement. Cet article de pganalyze, specialiste de la performance PostgreSQL, detaille les patterns qui permettent de le faire sans coupure de service.
Le premier anti-pattern identifie est la migration avec verrou de table. Certaines operations DDL comme l'ajout d'une contrainte NOT NULL sur une colonne existante ou la creation d'un index sans l'option CONCURRENTLY posent un verrou exclusif qui bloque toutes les lectures et ecritures. En production avec du trafic, c'est une interruption de service garantie.
La solution pour les index est systematiquement CREATE INDEX CONCURRENTLY, qui construit l'index en arriere-plan sans bloquer. Pour les contraintes, la strategie consiste a ajouter d'abord la contrainte en mode NOT VALID, puis a la valider avec VALIDATE CONSTRAINT dans une transaction separee.
Pour les colonnes NOT NULL, l'approche recommandee est en plusieurs etapes : ajouter la colonne avec une valeur par defaut, deployer l'application qui gere les deux etats (avec et sans la colonne), puis backfiller les donnees existantes, et enfin ajouter la contrainte NOT NULL une fois que toutes les lignes sont completes.
L'article insiste sur l'importance du rollback. Chaque migration devrait avoir un script de rollback teste. Avec Doctrine, cela signifie verifier que la methode down() de chaque migration est correcte et testee, pas juste ignoree.
La conclusion est que les migrations de production ne sont pas juste un probleme technique. Ce sont des operations qui demandent de la coordination entre l'equipe backend, les ops, et parfois le frontend. Documenter chaque migration, comprendre son impact sur le trafic et tester le rollback : ce sont des pratiques qui font la difference entre un deploiement tranquille et un incident.
Source : pganalyze.com/blog