Versionierung mit Liquibase

IFS-Logo Diese Seite ist ein Teil der IsyFact-Standards. Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt. Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.

Creative Commons Namensnennung Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.

Liquibase ist ein leistungsfähiges Tool zur Versionierung und Verwaltung von Datenbankänderungen. Es ermöglicht eine transparente, nachvollziehbare und automatisierte Änderungsverfolgung, wodurch manuelle Fehler minimiert und eine konsistente Synchronisation zwischen Entwicklungs-, Test- und Produktionsumgebungen sichergestellt wird.

Die Integration von Liquibase in eine bestehende Datenbank stellt eine Herausforderung dar, da das aktuelle Schema bereits produktiv genutzt wird. Ziel dieses Konzepts ist es, eine strukturierte Vorgehensweise zur Einführung von Liquibase zu definieren, ohne die bestehende Datenbankstruktur zu gefährden.

Eine konkrete Umsetzung dieses Konzepts folgt in Nutzungsvorgaben zur Versionierung mit Liquibase und dient als Empfehlung.

1. Ziele der Versionierung

Die Verwendung von Liquibase verfolgt mehrere Kernziele.

Nachvollziehbarkeit

Jede Änderung wird dokumentiert und kann jederzeit zurückverfolgt werden.

Automatisierung

Änderungen erfolgen nicht mehr manuell, sondern kontrolliert über Liquibase.

Konsistenz über verschiedene Umgebungen

Entwicklungs-, Test- und Produktionsumgebungen bleiben synchron.

Rollback-Funktionalität

Fehlerhafte Änderungen können gezielt zurückgesetzt werden.

2. Einführung von Liquibase

2.1. Vorbereitung und Installation

Liquibase wird direkt in die Anwendung integriert und kann automatisch mit dieser gestartet werden. Die wichtigsten Schritte umfassen die:

  • Einbindung in das Projekt über ein Abhängigkeitsmanagement,

  • Integration in das Anwendungsframework zur automatisierten Ausführung von Migrationen,

  • Bereitstellung von Datenbankänderungen im Rahmen von Deployment-Prozessen.

2.2. Konfiguration der Datenbankverbindung

Liquibase nutzt JDBC für die Datenbankkommunikation in Java- beziehungsweise Spring-basierten Anwendungen. Dabei sind folgende Punkte zu beachten:

  • Sicherstellen, dass sowohl Liquibase als auch die Anwendung über JDBC mit der Datenbank kommunizieren können.

  • Bereitstellung eines geeigneten Treibers für das verwendete Datenbanksystem.

  • Zentrale Verwaltung der Verbindungsinformationen innerhalb der Anwendung, um eine konsistente und sichere Nutzung der Datenbank zu gewährleisten.

2.3. Erfassung des bestehenden Schemas

Vor der Einführung von Liquibase in die IsyFact gab es eine eigens entwickelte Versionierung, die den aktuellen Zustand der Datenbank dokumentiert hat. Mit Liquibase wird ein Industriestandard verwendet, dessen Verwendung die Zukunftsicherheit verbessert und Abhängigkeiten von Eigenentwicklungen verringert.

Zum aktuellen Zustand gehören:

  • Tabellen, Spalten und Indizes,

  • Constraints und Relationen (Foreign Keys, Unique Constraints),

  • Views, Stored Procedures und Trigger,

  • Benutzerrechte und Berechtigungen.

Die Erfassung dieses Zustands bildet die Grundlage für eine Baseline, die als Startpunkt für die Versionierung mit Liquibase dient.

2.4. Erstellung der Baseline

Da das bestehende Schema nicht verändert, sondern lediglich in die Versionierung übernommen wird, wird eine Baseline erstellt. Diese dient als Referenzpunkt für alle zukünftigen Änderungen und sollte:

  • die gesamte bestehende Datenbankstruktur enthalten,

  • auf Redundanzen überprüft und bereinigt werden,

  • mit der Datenbank synchronisiert werden, sodass alle erfassten Änderungen als bereits angewendet gelten.

2.5. Integration in das Versionskontrollsystem

Die Baseline wird in das Versionskontrollsystem aufgenommen, um eine lückenlose Dokumentation und Nachvollziehbarkeit sicherzustellen. Liquibase führt eine Historie aller Änderungen in der Datenbanktabelle DATABASECHANGELOG und schützt vor parallelen Ausführungen über die Sperrtabelle DATABASECHANGELOGLOCK.

2.6. Fortlaufende Verwaltung von Änderungen

Nach der initialen Erfassung beginnt die kontinuierliche Versionierung der Datenbank.

Der Ablauf einer Änderung an der Datenbank ist typischerweise:

  1. Erstellung eines neuen Changelogs mit der geplanten Änderung.

  2. Aufnahme des Changelogs in das Versionskontrollsystem.

  3. Anwendung der Änderung über Liquibase.

  4. Tests und Freigabe der Änderung nach erfolgreicher Validierung.

Für eine reibungslose Verwaltung von Datenbankänderungen wird Liquibase direkt an den folgenden Stellen in den Entwicklungsprozess eingebunden:

  • Änderungen werden zuerst in isolierten Entwicklungsumgebungen getestet, bevor sie auf andere Umgebungen ausgerollt werden.

  • Die automatisierte Bereitstellung von Änderungen erfolgt über eine Integration in CI/CD-Pipelines.

  • Changelogs unterliegen Code-Reviews, um Konsistenz und Dokumentation sicherzustellen.

Liquibase stellt sicher, dass jede Änderung nur einmal und in der richtigen Reihenfolge ausgeführt wird, wodurch manuelle Fehler vermieden und die Konsistenz über alle Umgebungen gewährleistet wird.

3. Changelogs als zentrales Steuerelement

Das Changelog ist das zentrale Steuerelement der Liquibase-Versionierung. Es kann in verschiedenen Formaten erstellt werden, darunter XML, YML, SQL und JSON. Ein modularer Aufbau mit mehreren Dateien ist empfehlenswert, wobei das Root Changelog als Hauptdatei fungiert und andere Changelog-Dateien referenziert. Eine bewährte Praxis ist die versionsbasierte und release-orientierte Organisation (zum Beispiel changelog-1.0.xml, changelog-1.1.xml), um Änderungen pro Release zu bündeln.

3.1. Changeset: Die kleinste Einheit einer Änderung

Ein Changeset beschreibt eine einzelne Datenbankänderung und wird nur einmal angewendet.

Wichtige Prinzipien für die Verwaltung von Changesets sind:

  • Atomare Änderungen: Jede Änderung sollte einzeln und unabhängig sein.

  • Eindeutige Identifikation: Kombination aus ID, Autor und Changelog-Datei.

  • Verständliche Beschreibungen: Klare Dokumentation der Änderung.

  • Tests vor der Anwendung: Sicherstellen, dass Änderungen vor der Übernahme geprüft werden.

4. Umsetzung von Schemaänderungen

Die Umsetzung von Schemaänderungen erfolgt durch strukturiert definierte Changesets, die jeweils eine atomare Änderung repräsentieren. Dabei wird sichergestellt, dass jede Anpassung nachvollziehbar und unabhängig ist.

4.1. Definiertes Changeset für atomare Änderungen

Jede Änderung an der Datenbank erfolgt über ein Changeset, das in einer Changelog-Datei erfasst wird. Die Vorgehensweise umfasst:

  1. Planung der Änderung

    • Definition der konkreten Anpassung, wie das Hinzufügen einer Spalte oder das Erstellen einer neuen Tabelle.

    • Bewertung der Auswirkungen auf bestehende Daten und Abhängigkeiten.

  2. Erstellung eines Changesets

    • Dokumentation der geplanten Änderung in einer separaten Changelog-Datei.

    • Sicherstellung, dass jede Änderung einzeln und unabhängig bleibt, um Konflikte zu vermeiden.

  3. Validierung der Änderung

    • Prüfung auf Konsistenz und Kollisionen mit anderen Änderungen.

    • Tests in einer isolierten Umgebung, bevor die Änderung produktiv übernommen wird.

  4. Versionierung und Freigabe

    • Aufnahme des Changesets in das Versionskontrollsystem.

    • Überprüfung durch Code-Reviews, um sicherzustellen, dass die Änderung korrekt dokumentiert ist.

  5. Anwendung und Überwachung

    • Anwendung des Changesets auf die Datenbank über Liquibase.

    • Überprüfung der erfolgreichen Umsetzung durch Tests und Monitoring.

Durch diese strukturierte Vorgehensweise wird gewährleistet, dass Schemaänderungen sicher, nachvollziehbar und ohne unerwartete Seiteneffekte erfolgen.

5. Versionierung und Rollback-Strategie

5.1. Verwendung von Tags zur Versionierung

Liquibase ermöglicht das Setzen von Tags, um bestimmte Versionen oder Releases in der Datenbankhistorie zu markieren. Dies erleichtert:

  • Rollbacks auf eine vorherige Version,

  • die Wiederherstellung eines definierten Zustands, und

  • die Verwaltung von Deployments in Stages.

5.2. Rollback-Strategie

Ein strukturiertes Rollback-Konzept ist entscheidend für die Fehlerkontrolle. Es beinhaltet die folgenden Punkte:

  • Explizite Definition von Rollbacks: Jede Änderung sollte eine definierte Rückabwicklung enthalten.

  • Regelmäßige Tests: Sicherstellen, dass Rollbacks in einer Entwicklungsumgebung funktionieren.