Anwendungscode liegt seit Jahren in Git. In vielen Teams die Datenbank noch nicht. Das Schema lebt in der Produktion, Änderungen werden als Skripte auf irgendeinem Laptop geschrieben, und die einzige vollständige Aufzeichnung dessen, was sich geändert hat, ist die Datenbank selbst.
Das erschwert jede weitere Verbesserung. Eine Änderung, die Sie nicht sehen, können Sie nicht prüfen. Ein Deployment, das Sie nicht wiederholen können, können Sie nicht testen. Und ein Release lässt sich nicht automatisieren, wenn niemand sicher weiß, in welchem Zustand die Zieldatenbank ist.
In früheren Artikeln haben wir uns angesehen, was Redgate Flyway ist und warum Verzögerungen bei Datenbanken den Nutzen von Automatisierung verringern. Hier geht es um den ersten praktischen Schritt: eine bestehende Datenbank unter Versionskontrolle zu bringen.
Was Versionskontrolle Ihnen bringt
Sobald die Datenbank in Git liegt, hat jede Änderung einen Autor, ein Datum und einen Grund. Änderungen laufen durch dieselben Pull Requests wie Anwendungscode, sodass eine Datenbankspezialistin oder ein Datenbankspezialist sie prüfen kann, bevor sie die Produktion erreichen, und nicht erst danach. Und weil die Skripte im Repository liegen, lässt sich jede Umgebung aus derselben Quelle aufbauen.
Auch das Gespräch über Releases ändert sich. Die Frage lautet nicht mehr, wer was wo ausgeführt hat. Sondern auf welcher Version eine Datenbank steht.
Beginnen Sie mit dem, was heute läuft
Die meisten Teams starten nicht mit einer leeren Datenbank. Die erste Aufgabe ist, den aktuellen Zustand als Ausgangspunkt festzuhalten.
Mit Flyway gibt es zwei übliche Wege. Sie können das bestehende Schema als erste Migration skripten, sodass sich eine neue Umgebung von Grund auf aufbauen lässt. Oder Sie teilen Flyway mit flyway baseline mit, dass eine bestehende Datenbank bereits auf einer bestimmten Version steht, sodass nur spätere Änderungen angewendet werden. Die meisten Teams brauchen beides: ein Skript, das eine saubere Datenbank für Entwicklung und Test aufbaut, und eine Baseline für die Produktionsdatenbanken, die es schon gibt.
Vergleichen Sie Ihre Umgebungen, bevor Sie etwas festhalten. Entwicklung, Test und Produktion stimmen selten genau überein. Ein während eines Incidents hinzugefügter Index oder eine direkt in der Produktion korrigierte Prozedur lässt sich jetzt leichter klären als nach einem fehlgeschlagenen Deployment.
Versionieren Sie von da an jede Änderung
Ab der Baseline ist jede Änderung ein Migrationsskript im Repository. Flyway wendet Versioned Migrations der Reihe nach an und protokolliert jede in einer Schema-History-Tabelle in der Datenbank. So weiß Flyway immer, welche Skripte eine Datenbank bereits erhalten hat.
Ein paar Absprachen machen das in der Praxis tragfähig:
- Eine Änderung pro Migration, mit einem Namen, der sagt, was sie tut.
- Eine bereits ausgeführte Migration wird nie mehr bearbeitet. Eine Korrektur ist eine neue Migration.
- Views, Stored Procedures und Funktionen können Sie als Repeatable Migrations führen, die Flyway erneut anwendet, sobald sich ihr Inhalt ändert.
- Referenzdaten, auf die die Anwendung angewiesen ist, gehören ebenfalls unter Versionskontrolle. Kundendaten nicht.
Lassen Sie die Pipeline ausrollen
Mit der Datenbank in Git kann die Pipeline die Arbeit übernehmen, die bisher von Hand erledigt wurde. Ein Pull Request führt die Migrationen gegen eine Testdatenbank aus, sodass ein fehlerhaftes Skript im Build scheitert und nicht in einem Wartungsfenster. Nach der Freigabe durchlaufen dieselben Skripte in derselben Reihenfolge Test, Abnahme und Produktion.
Flyway läuft über die Kommandozeile und passt damit in Azure DevOps, GitHub Actions oder jedes andere CI-System. Teams auf GitHub können die Flyway Actions von Redgate nutzen.
Je nach Edition und Datenbankplattform ergänzt Flyway Prüfungen, die Reviewern helfen: Berichte darüber, was ein Deployment ändern wird, automatisierte Codeprüfungen und eine Drift-Erkennung, die ein Release stoppt, wenn die Produktion außerhalb des Prozesses geändert wurde.
Häufige Bedenken
Unsere Datenbank ist zu groß oder zu alt. Die Größe zählt bei den Daten, nicht beim Schema. Eine Baseline erfasst die Struktur, und Flyway wendet nur die Änderungen an, die danach kommen.
Unsere DBAs verlieren die Kontrolle. Sie gewinnen sie. Sie prüfen jede Änderung im Pull Request, und in die Produktion gelangt nur, was freigegeben wurde. Der Zugriff auf die Produktion kann auf die Pipeline beschränkt bleiben.
Wir machen Notfall-Fixes direkt in der Produktion. Manchmal ist das nötig. Vereinbaren Sie, dass jeder Notfall-Fix anschließend ins Repository übernommen wird, und nutzen Sie die Drift-Erkennung, um die Fälle zu finden, in denen das nicht passiert ist.
Wo Sie anfangen
Wählen Sie eine Anwendung, deren Datenbank sich oft ändert und Reibung verursacht. Vergleichen Sie ihre Umgebungen, legen Sie eine Baseline fest und schicken Sie die nächste Änderung durch einen Pull Request und eine Pipeline. Eine Routineänderung, die ohne manuellen Schritt in die Produktion gelangt, überzeugt mehr als jede Präsentation.
Masterminds ist langjähriger Redgate Gold Partner. Unsere DevOps- und Data-Teams unterstützen bei der ersten Bewertung, der Baseline und der Pipeline, siehe Database Automation mit Redgate Flyway. Nehmen Sie Kontakt auf, wenn Sie Ihre erste Datenbank unter Versionskontrolle bringen möchten.
