Liquibase ist ein System, um Datenbankschema-Änderungen festzuhalten und per SCM nachvollziehen zu können. Diese Änderungen können in XML, YAML, JSON oder SQL geschrieben werden und enthalten datenbankunabhängige Anweisungen. Liquibase kümmert sich dann darum, die Konvertierung für die jeweilige Datenbank zu übernehmen.
Zudem kann es Migrations-Skripte erstellen, oder eingebettet als Anwendungsbestandteil die Datenbank direkt (beim Hochfahren der Anwendung) auf den aktuellen Stand bringen.
Im Folgenden stelle ich meine persönlichen Empfehlungen bei der Verwendung von Liquibase vor:
- Liquibase Changelogs sollten immer im SCM eingecheckt werden. Dies stellt sicher, dass zusammen mit dem Source Code der dazugehörige Zustand des Datenbankschemas gesichert ist.
- Liquibase Changelogs sollten als unveränderlich wahrgenommen werden. Sobald der Changelog einmal auf einer Datenbank angewendet wurde, kann es nicht mehr ohne weiteres geändert werden. (Liquibase benutzt intern die Informationen über bereits angewendete Changelogs, um die notwendigen Statements zur Migration zu erzeugen.)
- Es ist sehr empfehlenswert, eine Master Liquibase Datei zu haben, die selber keine Changelogs enthält, sondern stattdessen die Changelogs von anderen Dateien inkludiert. Dieses erhöht zudem die Übersicht erheblich.
<include file=”liquibase/version-1.xml” />
<include file=”liquibase/patch-1.1.xml” />
<include file=”liquibase/version-2.xml” />
- Elemente mit optionalem Namen sollten immer explizite Namen bekommen. Z. B. Constraints, da ansonsten viele Datenbanksysteme einen generierten und nicht vorhersagbaren Namen verwenden werden. Insbesondere bei späteren Migrationen kann es erhebliche Probleme verursachen, da es nicht mehr möglich ist, diese direkt (über ihren Namen) zu löschen.
- Bei Changesets immer den logicalFilePath angeben. Hintergrund ist, dass Liquibase je nach Einbindung entweder per Classpath (z. B. bei der Spring Integration) oder per Datei (z. B. Maven-Plugin) die Changesets auflöst. Wenn kein logicalFilePath angegeben wird, dann ist die Tabelle mit den angewendeten Changesets in der Datenbank nicht mehr kontextunabhängig, und spätere Änderungen der Liquibase-Integration können Probleme verursachen.
- Liquibase kennt mehrere verschiedene Formate, um Changelogs zu beschreiben. Meine Empfehlung ist in diesem Fall XML, da ein sauberes XML-Schema vorliegt, welches es einem ermöglicht, auf IDE-Support/Auto-Complete zuzugreifen und zudem strukturell validiert werden kann. Auch bei der Verwendung von XML ist es weiterhin möglich, freie native SQL-Queries zu benutzten.
