Steve, Softwareentwicklung ist heute von agilen Prozessen geprägt – heißt: kurze Entwicklungszyklen, schnelle Releases, Continuous Delivery & Integration. Stellt das eigentlich auch Datenbankenschemata und Datenbankänderungen vor neue Herausforderungen? Und wenn ja, vor welche?
Im agilen Vorgehen, insbesondere durch das YAGNI-Prinzip („You Aren‘t Gonna Need It“), entwickeln sich auch Datenbankschemata iterativ weiter und benötigen häufiger Änderungen und Anpassungen.
Continuous Integration bedeutet, dass alle Änderungen automatisiert getestet werden. Hierbei kommen spezielle CI-Systeme zum Einsatz, die den neusten Entwicklungsstand automatisiert bauen und testen. Ändert sich das Datenbankschema, bedeutet das, dass das CI-System dies mitbekommen muss – im Besten Fall automatisiert.
Bei Continuous Deployment/Delivery ist dies sogar noch wichtiger, da die Automatisierung bis zum Produktivsystem reicht. Wird hier die Datenbank nicht richtig aktualisiert, kann das zu einem Ausfall führen. Zusätzlich muss man noch Eigenheiten des CD beachten: i. d. R. laufen mehrere Versionen der Software für gewisse Zeit parallel, da die neue Version rollierend verteilt wird, um eine Downtime zu vermeiden. Hier muss der Entwickler auf Kompatibilität achten.
Es geht also um Automatisierung. Kannst du kurz erklären, was Liquibase ist und welche Vorteile es in diesem Umfeld mitbringt?
Liquibase ermöglicht dem Entwickler, automatische Migrationsskripte für die Datenbank zu schreiben. Liquibase achtet darauf, dass die Skripte nur einmal ausgeführt werden und sich anschließend nicht mehr ändern. Die Updateskripte werden dabei mitversioniert und stehen somit auch dem CI/CD-System zur Verfügung. Dadurch wird es dem CI-System möglich, die neuen Skripte gegen den vorherigen Softwarestand zu testen und so die Kompatibilität sicherzustellen.
Hat das Auswirkungen auf die Gesamtqualität der ausgelieferten Software und/oder auf die Effizienz im Entwicklungsprozess?
Ein automatisierter Weg für Schema-Updates ist definitiv ein Effizienzgewinn: Der Entwickler braucht nicht jede Datenbank zu kontaktieren, um sie zu aktualisieren. Dadurch wird auch verhindert, dass eine Datenbank oder eine Anweisung übersehen wird. Sowas führt nämlich oft zu langsam auseinanderdriftenden Datenbankständen – und am Ende kann sich der Entwickler nicht mehr sicher sein, dass sein Entwicklungsstand noch zur Produktivdatenbank passt.
Wie sieht es mit der Performance von Datenbankabfragen aus, wenn Liquibase im Einsatz ist?
Liquibase ändert an der Performance an sich erst mal nichts. Durch die Versionierung wird es aber möglich, die Schemata laufend an wachsende Anforderungen anzupassen – z. B. durch neue Indices, Views und dergleichen – oder Datenstrukturen umzugestalten.
Gibt es bestimmte Branchen oder Anwendungsfelder, wo der Einsatz von Liquibase besonders zu empfehlen ist?
Liquibase ist ein Tool, das man überall einsetzen kann. Insbesondere wenn der Entwickler keinen direkten Zugriff auf die produktive Datenbank hat oder haben soll. Das gilt nicht nur für Server-Software wie Web-Anwendungen, sondern auch für Desktop-Software mit eigener Datenbank.
Was rätst du Entwicklern, die Liquibase zum ersten Mal integrieren möchten?
Überlegt euch, wie ihr Liquibase integrieren wollt: entweder als Teil einer separaten Update-Routine oder integriert in den Anwendungsstart. Beides hat Vor- und Nachteile.
Achtet darauf, dass Liquibase relative Pfade in sein Changelog schreibt. Hintergrund: Liquibase merkt sich den Script-Namen inkl. Pfad. Ändert sich der Pfad, werden die Skripte als neu angesehen und ausgeführt.
Welche Empfehlungen gibst du Kunden, die vor der Entscheidung für oder gegen den Einsatz von Liquibase stehen?
Es gibt eigentlich keinen Grund gegen eine Schema-Versionierung. Denn der Technologiestack wird durch Liquibase nur minimal vergrößert, die zu investierende Zeit ist relativ gering – doch der Nutzen ist enorm.
Neben Liquibase ist z. B. Flyway beliebt. Beide können zwar prinzipiell das gleiche, haben aber etwas andere Vorgehensweisen (z. B. Semantic Versioning vs. Changesets), Annahmen und Lizenzmodelle. Hier sollte man prüfen, ob das Tool in den eigenen Prozess passt und ob man eine kommerzielle Variante braucht. I. d. R. reicht für den Start die Open-Source-Variante.
Vielen Dank für dieses Gespräch, Steve.
Empfehlung: Passend zum Thema hier auch das TechShorty mit Steve zu Liquibase.
