Eine Datenbank ändert sich im Lauf eines Projekts ständig. Eine neue Spalte, eine zusätzliche Tabelle, ein Index, eine Umbenennung. Zieht man solche Änderungen von Hand auf jedem System nach, laufen Entwicklung, Testumgebung und Betrieb früher oder später auseinander. Und dann weiß niemand mehr, welcher Stand wo gilt.
Eine Migration ist eine kleine Datei, die genau einen Änderungsschritt beschreibt, dazu den Weg zurück. Sie liegt im selben Repository wie der Code und wird zusammen mit ihm versioniert. Ein Befehl spielt alle noch nicht angewendeten Schritte ein, in der richtigen Reihenfolge.
Warum das wichtiger ist, als es klingt
Der eigentliche Wert liegt in der Nachvollziehbarkeit. Jeder Umgebungsstand lässt sich aus dem Repository herstellen. Ein neuer Entwickler hat nach zwei Befehlen eine funktionierende Datenbank. Ein Deployment bringt die passenden Strukturänderungen von selbst mit.
Eine Regel hat sich dabei bewährt. Eine Migration, die schon einmal auf dem Produktivsystem gelaufen ist, ändert man nicht mehr. Was noch fehlt, kommt als neue Migration hinterher. Sonst stimmen die Stände nicht mehr überein.