Migrations et seeds

Prérequis : cours précédents ; migrations.

Pourquoi

Le schéma évolue avec le code : sans discipline, dev/staging/prod divergent et chaque déploiement est une loterie. Migrations versionnées + seeds rejouables = environnements identiques, déploiements ennuyeux (au bon sens).

Concepts

• Migration : un fichier numéroté (004_….sql), transactionnel, appliqué une fois (table schema_migrations). Up ET down testés (la down n'est pas optionnelle si le rollback l'exige).
• Seeds : données initiales/nécessaires (rôles, config, cursus de démo). Idempotents (ON CONFLICT DO NOTHING/UPDATE) : rejouables sans doublons — jamais de INSERT brut.
• Séparation : migrations (schéma, irréversibles par nature) vs seeds (données, rejouables) vs fixtures de test (jetables). Mélanger = ne plus savoir quoi rejouer où.
• CI : migrer une base vierge + jouer les seeds à chaque pipeline : la preuve que repartir de zéro marche (sinon, on le découvre en prod).

Exemple : seed idempotent

INSERT INTO roles (slug, label) VALUES ('admin', 'Admin')
ON CONFLICT (slug) DO UPDATE SET label = EXCLUDED.label;
-- rejouable 100 fois, 1 seule ligne admin

Cas réel

Seed INSERT brut rejoué en staging : 3 lignes admin, 12 devises en double, appli qui affiche tout en triple. Depuis : ON CONFLICT partout + CI qui rejoue les seeds sur base vierge.

Pièges

• Migration destructive + données (« DROP + recréer ») : perte en prod. Expand-then-contract (DevOps 4.3), toujours.
• Seeds avec données de test en prod (« user test/test ») : porte ouverte + pollution. Seeds prod = minimales et sûres.
• Numérotation à la main en équipe : collisions. Timestamps (20260101120000_) ou outil qui verrouille.

À retenir

Migrations transactionnelles + down, seeds idempotents, CI qui rejoue tout sur base vierge.