Liquibase & Flyway

Liquibase ist ein Open-Source-Tool zur Versionsverwaltung von Datenbankschemata. Es ermöglicht, Änderungen an Tabellen, Spalten oder Daten als sogenannte ChangeSets zu definieren. Diese werden automatisch versioniert, beim Deployment ausgeführt und in einer Historientabelle protokolliert.

Ist Tool für der Versionsverwaltung von Datenbankschemata. Sie sorgen dafür, dass Datenbankänderungen – also Tabellen, Views, Constraints oder Datenmigrationen – versioniert, nachvollziehbar und automatisiert deployt werden. Dadurch können Änderungen sicher über CI/CD verteilt und bei Bedarf zurückgerollt werden.

Beide dienen demselben Zweck – Migration und Versionierung von Datenbanken. Flyway arbeitet primär skriptbasiert mit SQL-Dateien, Liquibase dagegen deklarativ mit XML, YAML oder JSON. Liquibase bietet zusätzlich Rollback-Funktionen, Preconditions und Schema-Vergleiche (diff).

Liquibase speichert jede ausgeführte Änderung in einer eigenen Tabelle DATABASECHANGELOG. Dort steht, welches ChangeSet wann und von wem ausgeführt wurde. So erkennt Liquibase beim nächsten Lauf automatisch, welche Änderungen noch fehlen.

Ein ChangeLog ist die übergeordnete Datei, die eine Sammlung von ChangeSets enthält. Jedes ChangeSet beschreibt genau eine atomare Änderung. ChangeSets werden anhand einer Kombination aus ID und Autor eindeutig identifiziert.

Liquibase erlaubt explizite Rollbacks pro ChangeSet – man kann im ChangeSet-Block angeben, was beim Zurücksetzen passieren soll.

Man sollte ChangeSets nie direkt ändern, nachdem sie ausgeführt wurden, weil Liquibase sonst Checksum-Fehler meldet. Stattdessen erstellt man ein neues ChangeSet mit einer neuen ID, das die Korrektur enthält. So bleibt die Historie nachvollziehbar.

Liquibase markiert das ChangeSet in der Datenbank als fehlerhaft, und die Transaktion wird – wenn unterstützt – zurückgerollt. Danach kann man das Problem korrigieren und die Migration erneut ausführen.

Liquibase unterstützt Datenbankdialekte über eigene changeTypes. Wenn ich plattformunabhängig bleiben möchte, verwendet man generische Changes wie createTable statt SQL. Bei Datenbankspezifika kann man dbms="oracle" oder dbms="postgresql" im ChangeSet verwenden.

Die ChangeLogs selbst dienen als Dokumentation, weil sie deklarativ sind. Ansonsten schreibet man pro Release ein kurzes Schema-Änderungsprotokoll, das in Confluence oder im Repository abgelegt wird – mit Link zu den entsprechenden ChangeSets.

Eine Datenbankmigration ist eine kontrollierte Änderung der Datenbankstruktur oder -daten. Sie stellt sicher, dass alle Umgebungen denselben Schema-Stand haben. Migrationen sind versioniert und reproduzierbar.

Manuelle Skripte sind fehleranfällig und schwer nachvollziehbar. Oft ist unklar, welche Änderungen bereits ausgeführt wurden. Migrationstools lösen dieses Problem durch Versionierung.

Flyway ist ein leichtgewichtiges Migrationstool, das SQL-basierte Migrationen ausführt. Migrationen werden anhand von Versionsnummern gesteuert. Der Fokus liegt auf Einfachheit und Klarheit.

Flyway nutzt eine Metadatentabelle namens flyway_schema_history. Dort werden ausgeführte Migrationen protokolliert. So erkennt Flyway den aktuellen Stand.

Eine Baseline markiert einen bestehenden Datenbankzustand als Startpunkt. Sie wird genutzt, wenn Flyway in bestehende Projekte integriert wird. Frühere Migrationen werden dabei übersprungen.

Repeatable Migrationen werden bei Änderungen erneut ausgeführt. Sie werden häufig für Views oder Stored Procedures genutzt. Flyway erkennt Änderungen über Checksummen.

Preconditions prüfen Bedingungen vor der Ausführung eines ChangeSets. Sie verhindern fehlerhafte Migrationen. Beispielsweise kann geprüft werden, ob eine Tabelle existiert.

Liquibase diff vergleicht zwei Datenbankschemata. Unterschiede können automatisch in ChangeSets überführt werden. Das ist hilfreich bei Legacy-Systemen.

Liquibase kann über Starter-Dependencies eingebunden werden. Migrationen laufen automatisch beim Application-Start. Die Konfiguration erfolgt über application.yml.

Flyway ist standardmäßig in Spring Boot enthalten. Migrationen werden beim Start automatisch ausgeführt. SQL-Skripte liegen im Ordner db/migration.

Deklarative Migrationen sind datenbankunabhängig. Sie erhöhen Lesbarkeit und Wartbarkeit. Liquibase nutzt diesen Ansatz standardmäßig.

Flyway eignet sich für Teams, die SQL bevorzugen. Es ist einfacher und weniger komplex. Besonders gut passt es zu datenbanknaher Entwicklung.

Liquibase ist ideal für komplexe Enterprise-Projekte. Es bietet Rollbacks Preconditions und Multi-DB-Support. Das erhöht Kontrolle und Sicherheit.

Ein Rollback setzt eine Migration kontrolliert zurück. Es wird bei fehlerhaften Releases benötigt. Liquibase unterstützt Rollbacks nativ.

Flyway fokussiert Vorwärtsmigrationen. Rollbacks müssen meist manuell umgesetzt werden. Das erfordert disziplinierte Prozesse.

Schema Drift entsteht, wenn Datenbanken unterschiedliche Zustände haben. Migrationstools verhindern diesen Zustand. Sie sorgen für Konsistenz.

Migrationen werden automatisiert in Pipelines ausgeführt. So wird sichergestellt, dass jede Umgebung konsistent ist. Fehler werden früh erkannt.

Eine idempotente Migration kann mehrfach ausgeführt werden ohne Schaden. Das erhöht Sicherheit bei Deployments. Preconditions helfen dabei.

Migrationen werden gegen Testdatenbanken ausgeführt. Automatisierte Tests prüfen Schema und Daten. So lassen sich Fehler früh erkennen.

Fehlerhafte Migrationen können Datenverlust verursachen. Lange Laufzeiten können Deployments blockieren. Daher sind Tests und Backups essenziell.