Ein fehlerhaftes Deployment lässt sich zurücknehmen. Eine fehlerhafte Migration oft nicht.
Sobald ein ALTER TABLE durchgelaufen ist, existiert der vorherige Zustand nur noch im
Backup — und ob das wirklich einspielbar ist, weiß man erst, wenn man es braucht.
Deshalb verdient dieser eine Schritt im Deployment mehr Sorgfalt als der Rest zusammen. Fünf Mechanismen, die sich in der Praxis bewährt haben.
1. Versionierte Migrationsdateien statt manueller Skripte
Schemaänderungen gehören in dateibasierte Migrationsskripte, die einer Release-Version zugeordnet sind — nicht in ein Wiki, nicht in die Zwischenablage eines Kollegen. Nur so lässt sich überhaupt beantworten, welchen Stand eine Datenbank gerade hat.
2. Hash-Prüfung gegen nachträgliche Änderungen
Der häufigste Weg in die Katastrophe: Jemand korrigiert eine bereits ausgeführte Migrationsdatei nachträglich. Auf dem eigenen Rechner sieht alles gut aus — die Datei wurde ja nie erneut ausgeführt. Auf jedem System, das die Migration noch vor sich hat, läuft danach etwas anderes.
Eine Prüfsumme über jede ausgeführte Datei erkennt das sofort. RayMigrator validiert deshalb Hashes und meldet Abweichungen, statt sie zu übergehen.
3. Fehlerverhalten, das zur Migration passt
Nicht jede Migration soll bei einem Fehler dasselbe tun. Ein Index, der schon existiert, ist verschmerzbar. Eine halb angelegte Tabellenstruktur nicht.
RayMigrator kennt deshalb mehrere Fehleraktionen — Terminate, Rollback,
RollbackErrorOnly, RollbackRelease, Ignore — und lässt sie pro Produkt, pro
Verzeichnis oder pro einzelner Datei festlegen.
4. Transaktionen, wo die Datenbank sie hergibt
Nicht jede Datenbank kann DDL in Transaktionen. PostgreSQL kann es, MySQL in weiten Teilen nicht. Ein Werkzeug, das so tut, als wäre das überall gleich, erzeugt ein falsches Sicherheitsgefühl. Die Transaktionssteuerung gehört pro Migration konfigurierbar — und muss respektieren, was die jeweilige Engine tatsächlich leistet.
5. Verwaiste Läufe erkennen
Wenn der Migrationsprozess mitten im Lauf abbricht — Netzwerk weg, Pod neu gestartet, Strom weg —, bleibt ein Eintrag zurück, der „läuft gerade” behauptet. Ohne Erkennung solcher verwaisten Läufe blockiert dieser Eintrag alle folgenden Migrationen, oder schlimmer: Er wird ignoriert und die Migration läuft doppelt.
Das Muster dahinter
Alle fünf Punkte laufen auf dasselbe hinaus: Die Migration muss wissen, in welchem Zustand sie die Datenbank vorfindet, und was zu tun ist, wenn dieser Zustand nicht der erwartete ist. Werkzeuge, die von einem Idealverlauf ausgehen, funktionieren in der Entwicklung hervorragend und versagen im Betrieb.
RayMigrator ist unsere Antwort darauf — für SQL Server, PostgreSQL, MariaDB, MySQL und SQLite. Der Quelltext liegt auf GitHub.