Aller au contenu
EdgeServers
Blog

Les migrations Laravel qui cassent la production — et les patterns sûrs que nous utilisons à la place

27 mai 2026 · 1 min de lecture · par Sudhanshu K.

Il y a une catégorie de migrations Laravel qui marche toujours sur staging et casse fréquemment la prod : renommer une colonne, drop une colonne, changer un type, ajouter un NOT NULL sur une table peuplée. Le pattern est le même dans chaque cas — le changement de schéma nécessite un lock complet de table ou un cutover coordonné avec le déploiement, et les défauts Laravel ne vous donnent ni l'un ni l'autre.

Voici la discipline de migration-safety que nous appliquons à chaque client Laravel managé avec une base non triviale.

Le rename sûr en deux étapes

// Migration 1 — deploy
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable();   // ajouter la nouvelle colonne
});
// Backfill via un queue job, pas dans la migration
 
// Migration 2 — déployée seulement après que le backfill soit terminé
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable(false)->change();
    $t->dropColumn('email');                   // drop l'ancienne colonne
});

La règle : chaque « rename » ou « type change » devient deux déploiements avec un backfill au milieu. Le premier déploiement ajoute la nouvelle colonne. Le code applicatif apprend à lire et écrire les deux. Un job en arrière-plan fait le backfill. Une fois le backfill terminé et l'application ne lisant plus l'ancienne colonne, le deuxième déploiement la supprime.

L'article complet couvre :

  • Le piège « marche sur la petite table de staging » (les locks de table scalent avec le nombre de lignes)
  • Discipline --pretend — lire le SQL réel avant de l'exécuter
  • Outils de schema change online (gh-ost, pt-online-schema-change) pour les cas où les migrations Laravel ne suffisent pas
  • Faire le backfill via des queue jobs, pas via des migrations
  • Le template de migration que nous standardisons pour les clients
  • Stratégie de rollback quand une migration a déjà tourné et que le déploiement échoue

Contactez-nous si votre dernière fenêtre de migration a été plus longue qu'elle n'aurait dû.

Article complet disponible

Lire l'article complet