Continuous Integration für Datenbanken

27. Februar 2014Kai Spichale

Continuous Integration (CI) ist ein bewährter Prozess in der Softwareentwicklung. Möglichst schnelles Feedback ist das Ziel: Je kürzer die Feedbackschleife von der Quellcodeänderung bis zur Testausführung, desto schneller können Entwickler eventuell entstandene Fehler erkennen und beheben. Martin Fowler empfiehlt in seinem bekannten Artikel zu diesem Thema, alle für einen Build notwendigen Elemente unter Versionskontrolle zu stellen. Als Beispiel nennt er unter anderem Skripte zur Erzeugung des Datenbankschemas. Das Besondere an Datenbankskripten ist, dass sie nicht nur dazu dienen eine Datenbank zu erzeugen, sondern auch vorhandene zu migrieren.

Kompliziert wird diese Aufgabe, sobald mehrere bestehende Systeme mit unterschiedlichen Datenbankständen existieren. Bei einem Softwareupdate muss gegebenenfalls auch die Datenbank auf die jeweils zur Anwendung passende Version migriert werden. Hierbei können spezielle Werkzeuge zur kontinuierlichen Datenbankmigration wertvolle Dienste leisten, denn sie decken folgende grundlegende Funktionen ab:

  • Datenbankversionierung: Die Version der Datenbank beziehungsweise des Datenbankschemas muss exakt zur Version der Software passen. Daher ist es wichtig, die Datenbank als integralen Bestandteil der Software unter Versionskontrolle zu stellen.
  • Datenbankmigrationsskripte: Neben Skripten zur Erzeugung von Datenbanken, sind Skripte zur Datenmigration notwendig, welche als Artefakte des Build-Prozesses entstehen.
  • Inkrementelle Migration: Die Essenz von Datenbank-Refactorings ist das Zerlegen schwieriger Migrationen in viele kleine, einfachere Migrationen, die nacheinander ausgeführt werden. Getreu dem Motto “if it hurts, do it more often” sollten die Migrationen möglichst häufig als Teil des CI-Prozesses ausgeführt werden.

Zu den bekanntesten Frameworks in diesem Bereich zählen Liquibase und Flyway. Beide Frameworks arbeiten mit Versionierung und erkennen, welche Migrationsschritte durchzuführen sind, um eine Datenbank von Version X auf Version Y zu aktualisieren. Flyway und Liquibase speichern aus diesem Grund die aktuelle Version direkt in einer zusätzlichen Tabelle in der Datenbank. Liegt beispielsweise eine Datenbank in Version 2.1 vor und soll diese auf Version 2.3 migriert werden, wird zunächst von 2.1 auf 2.2 und schließlich von 2.2 auf 2.3 migriert, sofern 2.2 die einzige Zwischenversion ist.

Liquibase

Liquibase ist in Java implementiert und steht dank Apache License 2.0 kommerziellen und nichtkommerziellen Projekten zur Verfügung. Gängige Datenbanken wie IBM DB2, MySQL, Oracle und Microsoft SQL Server werden unterstützt. Die Datenbankänderungen werden entweder mit einem spezifischen Datenbankdialekt oder mit einer datenbankneutralen Beschreibung in den sogenannten Database-Change-Log-Dateien definiert. Das folgende XML-Beispiel zeigt, wie das Attribut AUTO_INCREMENT der Tabelle person hinzugefügt wird, um eindeutige Ids für neue Datensätze zu verwenden:

 

Das ChangeSet wird dann zur Laufzeit von Liquibase in SQL − in diesem Fall für die Datenbank MySQL – übersetzt. Liquibase kann über die Kommandokonsole, Ant und Maven ausgeführt werden. Liquibase kann ebenfalls SQL-Skripte als Ergebnis erzeugen. Das ist ein praktisches Feature für Fälle, in denen für Auslieferungen Datenbankadministratoren ein fertiges SQL-Skript zum Review erwarten. Die im Beispiel gezeigte XML-Abstraktion, hilft inkompatible DDL-Skripte zu vermeiden. Rollback von Datenbankänderungen wird entweder durch automatisch erzeugtes oder benutzerdefiniertes SQL unterstützt. Liquibase kann außerdem das Datenbankschema aus einer bestehenden Datenbank extrahieren und Unterschiede zwischen zwei Datenbankinstanzen bestimmen.

Flyway

Auch dieses Framework ist in Java implementiert und steht unter der Apache License 2.0. Über die Kommandokonsole, Ant, Maven, Gradle, SBT sowie über eine Java API kann Flyway in den Build-Prozess eingebunden werden. Im direkten Vergleich mit Liquibase fällt sofort auf, dass Flyway leichtgewichtiger ist. Es gibt beispielsweise keine XML-Abstraktion, sodass die Migrationsschritte direkt in SQL oder Java formuliert werden:

 

Dieses Beispiel zeigt analog zum vorherigen, wie mit Flyway das Attribut AUTO_INCREMENT hinzugefügt werden kann. Flyway bietet gewisse Vorteile, wenn man Datenbankspezifische Features wie PL/SQL, Stored Procedures, LOBs und Datenbank-Dumps einsetzen möchte.

Fazit

Teams, die regelmäßig Datenbankmigrationen durchführen, sollten über den Einsatz von Flyway oder Liquibase nachdenken, denn mit beiden Frameworks können Migrationen gut strukturiert und versioniert werden. Der Funktionsumfang beider Open-Source-Werkzeuge ist vergleichbar und unterscheidet sich nur in Details. Liquibase bietet eine Datenbankabstraktion. Flyway punktet durch Leichtgewichtigkeit. Die beiden Werkzeuge sollten in keinem Repertoire mehr fehlen.

Haben Sie bereits Erfahrungen mit Flyway und Liqubase gesammelt? Ich freue mich auf Ihre Ansicht zu diesem Thema.

Kai Spichale Kai Spichale ist Software Architect bei der adesso AG. Sein Tätigkeitsschwerpunkt liegt in der Konzeption und Implementierung von Softwaresystemen auf Basis von Spring und Java EE. Er ist Autor verschiedener Fachartikel und regelmäßiger Sprecher auf Konferenzen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Bernd Schulz 22. Mai 2015 Website des Autors

HallO!
Wie löse ich denn das Problem der Dokumentation?
Liquibase hilft mir sehr gut bei der Versionierung der Datenbank und dem Rollout – super
Als Dokumenation erstellt es aber lediglich ChangeLogs, nett aber als Dokumentation der gesamten Datenbank vollkommen untauglich.
Auch scheint Liquibase an columns keine Kommentare anhängen.

Vielleicht umgekehrt?
Gibt es ein Datenmodellierungs-Tool, dass Liquibase mit den notwendigen Änderungen versorgt?

BYE BERND

Kommentar hinzufügen:

Ihr Kommentar: