Nicht beim Start
Der bequeme Weg ist, die Migration in den Startbefehl zu hängen. Bei einer Instanz geht das oft gut. Bei zweien starten zwei Migrationen gleichzeitig auf derselben Datenbank – und bei jedem Neustart erneut.
Besser: ein eigener, einmaliger Schritt nach dem erfolgreichen Build und vor dem Umschalten. Über die Kommandozeile der Plattform:
# Beispiele
npx prisma migrate deploy
bundle exec rails db:migrate
python manage.py migrateAbwärtskompatibel ändern
Während eines Deployments laufen kurz beide Fassungen. Die Migration muss zu beiden passen. Das heißt in der Praxis: in mehreren Schritten arbeiten.
| Ziel | Schritt 1 | Schritt 2 | Schritt 3 |
|---|---|---|---|
| Spalte umbenennen | neue Spalte anlegen, beide schreiben | Code liest die neue | alte Spalte entfernen |
| Spalte entfernen | Code hört auf, sie zu nutzen | deployen | Spalte entfernen |
| Pflichtfeld hinzufügen | optional anlegen, Standardwert füllen | Code füllt es | auf „nicht null“ setzen |
Große Tabellen
Eine Migration, die eine Million Zeilen sperrt, legt die Anwendung still, auch wenn sie technisch
durchläuft. Bei PostgreSQL Indizes mit CONCURRENTLY anlegen, große Datenänderungen in
Häppchen fahren und nicht zur Hauptlastzeit.
Häufige Fragen
Kann ich Migrationen zurücknehmen?
Technisch bieten die meisten Werkzeuge ein „down“. Verlass dich nicht darauf: Was gelöscht ist, kommt damit nicht zurück. Die Wiederherstellung aus der Sicherung ist der verlässlichere Weg.
Wie führe ich den Schritt aus?
Über die Kommandozeile im laufenden Container oder als einmalige Aufgabe. Beides ist in der Console erreichbar.