Zum Inhalt springen
EdgeServers
Blog

Die Laravel-Migrationen, die Produktion brechen — und die sicheren Patterns, die wir stattdessen nutzen

27. Mai 2026 · 1 Min. Lesezeit · von Sudhanshu K.

Es gibt eine Kategorie von Laravel-Migrationen, die immer auf Staging funktioniert und häufig Produktion bricht: eine Spalte umbenennen, eine Spalte droppen, einen Typ ändern, ein NOT NULL auf eine befüllte Tabelle hinzufügen. Das Muster ist in jedem Fall dasselbe — die Schemaänderung erfordert einen vollen Tabellen-Lock oder einen deploy-koordinierten Cutover, und Laravels Defaults bieten weder das eine noch das andere.

Dies ist die Migrations-Sicherheits-Disziplin, die wir auf jeden gemanagten Laravel-Kunden mit einer nicht-trivialen Datenbank anwenden.

Das sichere Zwei-Schritt-Rename

// Migration 1 — Deploy
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable();   // neue Spalte hinzufügen
});
// Backfill via Queue-Job, nicht in der Migration
 
// Migration 2 — erst deployen, nachdem der Backfill abgeschlossen ist
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable(false)->change();
    $t->dropColumn('email');                   // alte Spalte droppen
});

Die Regel: Jedes „Rename" oder „Typ-Change" wird zu zwei Deploys mit einem Backfill dazwischen. Der erste Deploy fügt die neue Spalte hinzu. Der Anwendungscode lernt, beide zu lesen und zu schreiben. Ein Background-Job macht den Backfill. Nachdem der Backfill abgeschlossen ist und die App die alte Spalte nicht mehr liest, entfernt Deploy zwei sie.

Der vollständige Beitrag behandelt:

  • Die „funktioniert auf kleiner Staging-Tabelle"-Falle (Tabellen-Locks skalieren mit Row-Count)
  • --pretend-Disziplin — das tatsächliche SQL lesen, bevor es läuft
  • Online-Schema-Change-Tools (gh-ost, pt-online-schema-change) für die Fälle, wo Laravel-Migrationen nicht reichen
  • Backfilling via Queue-Jobs, nicht via Migrationen
  • Die Migrations-Vorlage, die wir für Kunden standardisieren
  • Rollback-Strategie, wenn eine Migration schon gelaufen ist und der Deploy fehlschlägt

Melden Sie sich, wenn Ihr letztes Migrations-Fenster länger war, als es hätte sein sollen.

Vollständiger Artikel verfügbar

Vollständigen Artikel lesen