Was ist Flyway?

Flyway ist ein Open-Source-Tool zur Datenbankmigration, mit dem Entwickler Versionskontrollverfahren auf ihre Datenbanken anwenden können. Von Flyway an der Datenbank vorgenommene Änderungen werden als Migrationen bezeichnet. In Flyway gibt es zwei Arten von Migrationen: Sie können entweder versioniert oder wiederholbar sein, wobei die versionierte Migration am häufigsten vorkommt.

Warum ist Schemaversionierung notwendig?

Anwendungen müssen sich im Laufe der Zeit ändern und weiterentwickeln, wenn sie einen Wert haben sollen. Wenn sich Anwendungen weiterentwickeln, ändern sich auch Datenbanken, was eine Datenmigration erforderlich macht.

Diese Datenmigration ist erforderlich, wenn Datenbankschemata in Produktionsumgebungen aktualisiert werden und wenn Testserver, Stage-Server und sogar die lokalen Entwicklungsumgebungen von Entwicklern aktualisiert werden.

Bei iBCScorp™ haben wir Multi-Tenant-Anwendungen. Stellen Sie sich also vor, Sie hätten Hunderte oder Tausende von Datenbanken, die aktualisiert werden müssen. Migrationen ermöglichen es uns, dieselben Migrationen konsistent für alle Datenbanken und Anwendungen anzuwenden.

Merkmale von Flyway

Flyway bevorzugt Einfachheit und Konvention gegenüber Konfiguration.

Zu seinen Funktionen gehören unter anderem:

Java-Rückruf Und SQL-Rückruf)

Flyway basiert auf nur 7 grundlegenden Befehlen: Migrieren, Bereinigen, Info, Validieren, Rückgängig machen, Basislinie erstellen und Reparieren.

Flyway-Migration

Migrate ändert das Schema von einer Version zur anderen. Konkret führt es SQL für eine Datenbank aus und merkt sich, dass die Migration ausgeführt wurde, indem die Versionsnummer in der Flyway-Tabelle aufgezeichnet wird. Der Migrationsprozess ist einfach.

In der Regel wird der Code, der von der Migration abhängt, immer mit der Migration freigegeben, sodass die Anwendungsmigration reibungslos und problemlos verläuft. Mehr über

Wandernfinden Sie hier.

Bestätigen

Durch die Validierung wird sichergestellt, dass die Schemamigrationen in der Zieldatenbank korrekt und wie erwartet erfolgen.

Bestätigengeschieht standardmäßig zur Build-Zeit für unsere Anwendungen, und wenn es eine Änderung in einer Flyway-Datei gibt, wird uns der Build nicht anzeigen, dass ein Problem vorliegt, das gelöst werden muss. So lässt sich einfach sicherstellen, dass die Datenbankmigrationen ordnungsgemäß funktionieren und tatsächlich korrekt in der Produktion angewendet wurden.

Diese verwenden wir nicht: Sauber

Mit Clean kann die Datenbank bereinigt werden. Weitere Informationen finden Sie hier: Clean. Da die Migrationen so einfach zu wiederholen sind, konnten wir eine Datenbank problemlos löschen und neu beginnen.

Info

Der Info-Befehl gibt Einblick in den Status der Migration. Weitere Einzelheiten hier: Info. Da wir viel mit Multi-Tenant-SAAS- und PAAS-Anwendungen arbeiten, bei denen viele Datenbanken verwendet werden, finden wir es praktisch, einfach direkt die Flyway-Tabelle zu überprüfen.

Rückgängig machen

Wie der Name schon sagt, können wir hierdurch Änderungen rückgängig machen.

Rückgängig machenwurde von uns jedoch nie verwendet. Das liegt daran, dass wir zuerst gründlich testen und dann weitermachen. Das heißt nicht, dass wir keine Fehler machen, aber mit der Rollforward-Strategie haben wir, wenn wir etwas zurück ändern müssen, eine andere Migrationsstrategie, um diese Änderung vorzunehmen.

Ausgangslage

Durch die Erstellung einer Baseline kann der Startpunkt der Migration zurückgesetzt werden, sodass der Overhead in Skripten reduziert werden kann. In der Praxis bereinigen wir tatsächlich unsere Migrationsskripte und aktualisieren unseren Schemaverlauf auf eine sauberere Version, anstatt

Ausgangslage, obwohl es Situationen geben kann, in denen die Basislinie die bessere Option ist.

Reparieren

Dadurch wird Ihre Flyway-Tabelle repariert, sodass sie dem tatsächlich verwendeten Schema entspricht.

Reparierenist der König eines automatisierten Prozesses, wir verwenden dies normalerweise nicht und nehmen manuelle Anpassungen vor.

Erste Schritte mit Flyway und Spring Boot

Es ist ein natürlicher und einfach zu verwendender Flyway als Softwareversionierungstool mit einem Spring Boot- oder Spring-Framework. Viele Softwareentwickler verwenden dieses oder andere Migrationstools, um den Datenmigrationsprozess zu verwalten.

Flyway-Konfiguration für eine nahtlose Datenbankmigration

Best Practices für die Datenbankmigration mit Flyway

Flyway ist ein großartiges Tool zur Verwaltung von Datenbankmigrationen.

Flyway unterstützt Entwickler sofort dabei, eine Datenbank von Grund auf neu zu erstellen. Dies ist bei der Erstellung einer neuen Umgebung hilfreich und spart viel Arbeit. Migrationstools stellen sicher, dass eine Anwendung mit dem aktuellen Status der Datenbank ausgeführt wird. Dies kann beispielsweise verhindern, dass ein Entwickler auf einen Fehler „Spalte nicht gefunden“ stößt.

Aber wie verwenden Sie dieses Flyway-Migrationstool?

Dazu müssen wir zunächst die Gradle-Abhängigkeit hinzufügen und dann die restlichen Schritte ausführen.

Installation der Gradle-Abhängigkeit

Fügen Sie die Flyway-Abhängigkeit zu pom.xml hinzu für

Mavenproject oder build gradle wenn Sie verwendenGradle.

Pom.xml org.flywaydb flyway-core 6.4.3 build.gradle implementation ‘org.flywaydb:flyway-core:6.4.3’ Wenn Sie Flyway mit der Befehlszeile verwenden möchten, dann für Maven mvn flyway:info und für Gradle ./gradlew flywayInfo, und fügen Sie auch das folgende Plugin hinzu.

Maven

org.flywaydb 
flyway-maven-plugin 
6.4.3

Gradle

Plugins {

ID „org.flywaydb.flyway“ Version „6.4.3“

}

Einige der gebräuchlichen Befehle, die wir verwenden können

Maven Gradle Beschreibung wandernFlugwegMigrantInnenMigrieren der DatenbanksauberflywayCleanLöscht alle Objekte im konfigurierten Schema.InfoFlugrouteInfoDruckt die Details und Statusinformationen aller Migrationen.

Konfiguration

In diesem Abschnitt werden die für Flyway erforderlichen Erstkonfigurationen erläutert.

Flyway-Konfiguration eines neuen Projekts

Aktualisieren

src/main/resources/application.properties

um Ihre

spring.anwendung.name

=DemoFlugweg

                spring.datasource.url=
jdbc:postgresql://localhost:5432/demoflywaydb?createDatabaseIfNotExist=true


                spring.jpa.hibernate.ddl-auto=aktualisieren
                
                
spring.datasource.benutzername=postgres

                spring.datasource.password
=test123

                spring.datasource.platform=
postgresql

                spring.jpa.hibernate.ddl-auto=aktualisieren
                




                # Flugroute
                spring.flyway.schemas=
Migrationen


                Frühling.Flugwege.Standorte=Klassenpfad:db/Migration



                
# Datenquelle
                spring.datasource.hikari.schema
=
Migrationen

            
            
            Erstellen einer Migrations-SQL-Datei

            Flugrouteliest die Migrationsskriptdateien standardmäßig aus dem Verzeichnis src/main/resources/db/migration. Im vorherigen Schritt haben wir den Speicherort für die Migrationsdatei definiert, der sich in

            src/main/Ressourcen/db/Migration.


            Für die Migrationsdatei gilt eine eigene Namenskonvention, die strikt eingehalten werden muss.
            Das Migrationsdateiformat =
<Präfix> <Version>__<Beschreibung>.sql</Beschreibung> </Version> </Präfix>

Erstellen Sie eine neue Datei mit der folgenden Namenskonvention

Präfix: Standardmäßig V.

Versionen: Punkte oder Unterstriche in beliebig viele Teile aufgeteilt Trennzeichen: Standardmäßig _ _ (zwei Unterstriche) und trennt die Version von der Beschreibung.

Beschreibung: Ein Text mit durch Unterstriche oder Leerzeichen getrennten Wörtern.

Suffix: Standardmäßig .sql.

Für unser Tutorial auf GitHub haben wir V1_ _ Initial.sql erstellt.

ERSTELLEN

SEQUENZ users_seq

MIT 50
1
9223372036854775807
10000
1

NEIN

ZYKLUS;

TABELLE ERSTELLENBENUTZER (
                testUser_id int8 
NICHT NULL STANDARDnächsterWert('Benutzer_Seq'
::reg-Klasse),
                testBenutzername VARCHAR
(45));


                EINFÜGEN INBENUTZER (Testbenutzername)
WERTE(test1
);


            Die Dateien im
src/main/resources/db/migration wird nach dem Hinzufügen anderer Migrationsdateien wie folgt angezeigt:
            
            

            Nach dem Ausführen der Anwendung und der erfolgreichen Ausführung können wir die in Ihrer Datenbank erstellten Tabellen USERS und flyway_schema_history sehen.

            

            Und in flyway_schema_history werden die Einträge aller Migrationen wie im Bild unten gezeigt eingetragen.

            
            

            Lauf-Flyway
            
Flyway unterstützt eine Reihe verschiedener Optionen zum Ausführen von Datenbankmigrationen:

            
                Befehlszeile

                Java-API
                Über Maven- und Gradle-Plugins und

über Community-Plugins und Integrationen wie Spring Boot

Automatische SpringBoot-Konfiguration

Wenn eine DataSource-Implementierung als Abhängigkeit im Klassenpfad definiert ist, kann Spring Boot diese DataSource problemlos instanziieren und für die Ausführung von Datenbankabfragen verfügbar machen. Anschließend wird die DataSource automatisch an die automatische Konfiguration von Flyway weitergegeben. Dazu muss unserer Build-Datei die folgende Abhängigkeit hinzugefügt werden (Gradle-Notation): implementierung 'org.flywaydb:flyway-core'

Standardmäßig führt Spring Boot Flyway-Datenbankmigrationen automatisch beim Start der Anwendung aus. Und die automatische Konfiguration von Spring Boot ist der einfachste Ansatz, der mit minimalem Aufwand sofort einsatzbereite Datenbankmigrationen unterstützt. migrations

Java-API

Auch hier müssen wir flyway als Abhängigkeit hinzufügen (Gradle-Notation): Implementierung 'org.flywaydb:flyway-core'

Jetzt müssen wir nur noch die Kernklasse Flyway als Teil der Anwendungsinitialisierung konfigurieren und ausführen:

importiere org.flywaydb.core.Flyway;

öffentliche Klasse MyApplication {

öffentliche statische void main(String[] args) {

Datenquelle Datenquelle = ...

Flugweg Flugweg = Flugweg.configure().dataSource(dataSource).load();

// Den Rest der Anwendung starten
}
Durch den Aufruf von flyway.migrate() werden nun alle Datenbankmigrationen ausgeführt, die noch nicht zuvor ausgeführt wurden.
Schema aufteilen

Wir teilen unser Schema normalerweise mit separaten Flyway-Migrationsdateien für jedes Schema auf. Wir verwenden nie das öffentliche Schema, sondern ein spezifisches Schema für jede natürliche Gruppierung unserer Datenbankobjekte. Dadurch können wir mehrere Migrationspfade für mehrere Module oder Gruppierungen von Microservices haben.

Das Flyway-Schema kann also mehrere Tabellen mit separaten Migrationspfaden enthalten, wie diese

Und zwar in jeder Kundendatenbank.

Schemakonventionen

Da wir häufig an Unternehmensanwendungen mit mehreren Modulen arbeiten, trennen wir die Module und trennen auch die Schemaverwaltung in die jeweiligen Module. Wenn es also ein Produktivitätsmodul gibt, wird das von diesem Modul verwendete Schema in dieser Codebasis verwaltet. Diese Module erhalten jeweils ihre eigene Flyway-Schemaverlaufstabelle, wodurch es einfacher wird, jedes Modul oder jede Microservice-Gruppe unabhängig von den anderen zu verwalten.

Versionierungskonventionen

            
Versionen müssen immer hochgestuft werden und werden in der Reihenfolge ihrer Nummer angewendet. Die Zeit schreitet auch voran, daher verwenden wir ein Datum als Teil unseres Versionierungsschemas. Beispielsweise könnte V2023.12.10.01__ads_user_table.sql eine Flyway-SQL-Datei zum Hinzufügen eines Benutzers sein, der die erste Migration am 10. Dezember 2023 war. Wir organisieren die Migrationsdateien außerdem nach Jahr und Monat, damit wir nicht nur ein Verzeichnis mit Hunderten von Migrationen haben.


            

            


            
Testdaten

            
Manchmal erfordert ein bestimmtes Modul für den Integrationstest ein Schema, das in diesem Modul nicht vorhanden ist. Wir verwenden spezielle Flyway-Migrationen, um unserer Anwendung Testschemata und Testdaten hinzuzufügen.

Diese Testabhängigkeiten fügen die notwendigen Testdaten für Migrationstests hinzu.

Aufräumen

Mit der Zeit können unsere Migrationsdateien sehr zahlreich werden. Das verlangsamt das Ausführen von Tests oder das Einrichten einer Entwicklungsumgebung. In regelmäßigen Abständen bereinigen wir die Dateien. Es kann sein, dass wir 5 oder 10 Dateien haben, die über ein oder zwei Jahre hinweg Aktualisierungen und Änderungen an einer Tabelle vornehmen. Wir können diese 10 Felder später durch nur eine Datei ersetzen, die die endgültige Tabelle in ihrer jetzigen Form erstellt. Dadurch können wir die Anzahl der Migrationen reduzieren und haben nur die endgültige Version.

Abschluss

In diesem Artikel haben wir erfahren, wie Flyway funktioniert und wie wir mit diesem Tool unsere Anwendungsdatenbank neu gestalten können.