Migrations sans couper la prod

Prérequis : cours 4.1 ; index et transactions.

Pourquoi

Déployer, c'est faire cohabiter un moment l'ancien code avec le nouveau schéma — le temps du restart, ou durablement si on déploie progressivement (rolling : conteneurs remplacés un par un ; bleu-vert : deux stacks complètes avec bascule — détaillés au chapitre 6). Toute migration qui casse l'ancien code = coupure garantie.

Concepts

• Expand-then-contract : ajouter sans casser (colonne nullable, table, index), déployer le code, nettoyer à la release suivante. Jamais de rupture en une fois.
• Idempotent : rejouable sans effet (grâce à schema_migrations) : relancer ne réapplique rien, échec = on peut recommencer sereinement.
• CREATE INDEX CONCURRENTLY : crée l'index sans verrouiller les écritures (un index normal bloque la table — sur des millions de lignes, c'est une coupure déguisée).
• Migration DOWN : le script inverse (annule la migration). Réparer en avant : l'alternative — corriger par une nouvelle migration au lieu de revenir en arrière.

Exemple : renommer sans casser

-- release 1 : ajouter, double écriture côté code
ALTER TABLE users ADD COLUMN full_name TEXT;
-- release 2 (plus tard) : bascule lecture, puis
ALTER TABLE users DROP COLUMN name;

Chaque fichier dans une transaction (BEGIN; … COMMIT;) : échec = rollback total, jamais de schéma à moitié appliqué.

Cas réel

RENAME COLUMN déployé un vendredi : l'ancien conteneur encore en ligne cherche l'ancien nom → 500 sur la moitié du trafic pendant 10 minutes. Avec expand-then-contract : zéro erreur, nettoyage le lundi suivant.

Pièges

• NOT NULL sans défaut sur table pleine : réécriture + verrouillage, coupure.
• DROP dans la même release que le code qui s'en sert encore.
• Migration non transactionnelle à moitié appliquée : schéma inconnu, rollback manuel.

À retenir

Ajouter d'abord (expand), déployer, nettoyer plus tard (contract) ; tout en transaction ; plan retour écrit avant (tag précédent, DOWN testée ou réparation en avant décidée).