Datenbankversionierung

Konzept, Technologien, Liquibase

David Lehner

Einführung

  • Verwaltung und Nachverfolgung von Änderungen

  • Änderungen (Anwendung auf verschiedenen Systemen)

Was ist das Problem?

  • Verlorene Informationen in der Entwicklung, Nachvollziehen von Änderungen

  • Fehlersuche / Rollback

  • Inkonsistenz zwischen verschiedenen Umgebungen

Beispiel (Ausgangssituation):

  • Teamstruktur

  • Neue Funktionalität fordert Datenbankänderung

Beispiel (Problem):

  • Umsetzung ohne Versionierung

  • Im Backend kommt es zu Fehlern

  • Rollback

  • Synchonisationsproblem

Wie wird das Problem gelöst?

  • Einsatz von Tools zur Datenbankversionierung wie Liquibase.

  • Zentralisierte Verwaltung von Datenbankänderungen (Versionierung)

  • Synchronisierung der Datenbank

  • Rollback-Mechanismus

  • Konsistenz

Liquibase

  • Open-Source-Lösung für Datenbankversionierung.

  • Unterstützt diverse Datenbanken (auch NoSQL)

Changelog

  • Changelog (File mit allen Änderungen)

  • Changeset (Enthält Änderung)

  • Änderungstyp (create…​, add…​)

simple changelog

Live DEMO

Aufsetzen

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-liquibase</artifactId>
</dependency>

Verwendung

Create, Delete, Update

  • Änderungen immer in ChangeLogs

    <changeSet author="david" id="1" labels="testing">
        <createTable tableName="quarkus">
            <column name="ID" type="VARCHAR(255)">
                <constraints nullable="false"/>
            </column>
            <column name="NAME" type="VARCHAR(255)"/>
        </createTable>
    </changeSet>

Rollback

  • liquibase rollback-count --count=2

  • -''- rollback --tag=test

  • auch programmatisch möglich

    <changeSet id="tag-quarkus" author="david" labels="testingAll">
        <tagDatabase tag="createQuarkusTable"/>
    </changeSet>

CLI

  • liquibase update

  • liquibase rollback --tag=tagname

  • liquibase rollback-count --count=4

  • liquibase generateChangeLog --changeLogFile=fileName

  • liquibase --output-file=<filename> snapshot --snapshot-format=<format(json…​)>

ORM

ORM

Best-Practices

  • Changelog Struktur

    • Root-ChangeLog

    • Files nach Versionen, oder Entitäten

  • Maximal eine Änderung pro ChangeSet

Mehrere Datenbanken

multiple dbs

Mehrere Datenbanken

liquibase update --changelog-file=masterChangelog.xml \
          --url=<Database URL> \
          --username=<username> \
          --password=<password>

Alternative

  • Flyway

Gleichheiten

  • Open-Source

  • Grundprinzip gleich

  • Basierend auf Java

  • CLIs vorhanden

  • Hohe Unterstützung verschiedener Datenbanken

Warum Liquibase?

  • Einfachere Darstellung von Veränderungen (SQL vs. SQL, XML, YAML, JSON)

  • Striktere Namensgebung bei Flyway

    • V = Versionised

    • U = Undo

    • R = Repeatable

    • BSP: V01__Add_New_Column.sql

Warum Liquibase?

  • Keine Filename Conventions bei Liquibase

  • Ein "Haupt-file" beinhaltet alle Veränderungen und Referenzen auf andere Files

  • Reihung klarer bei Liquibase

    • Liquibase: Nach definition in Root-File

    • Flyway: In Filename angeben

Workflow

Developer Workflow

Workflow

  1. ChangeSet erstellen, welches die Änderungen beinhaltet

  2. liquibase update - Datenbank ändern

  3. Änderungen am Code vornehmen, falls nötig

  4. Applikation mit Datenbank testen

  5. Commit von Applikation und Changeset

Vorteile

  • Änderungen gespeichert

  • Rollback feature, bei Fehlern oder arbeiten auf gemeinsamer DB

  • Fehleranfälligkeit vermindert

  • Einbindung in jeweilige CI/CD pipelines

Nachteile

  • Höherer Aufwand bei Erstellung des Projekts

  • Funktionalität mit ORM etwas umständlich

Vielen Dank!