Bevor Sie weitere Entwickler einstellen oder in eine weitere Delivery-Plattform investieren, lohnt sich ein Blick darauf, wie lange fertige Änderungen tatsächlich warten, bevor sie beim Kunden ankommen. Wenn Datenbankänderungen noch über einen separaten Prozess laufen und manuell ausgeführt werden müssen, führt zusätzliche Entwicklungskapazität nicht automatisch zu einer schnelleren Auslieferung.
Die Entwicklung ist zu diesem Zeitpunkt bereits bezahlt. Solange die neue Funktion nicht produktiv ist, bleiben auch der erwartete Umsatz oder die geplanten Einsparungen aus.
Wo die Kosten entstehen
Nehmen wir die Aktualisierung eines Kundenportals, an der vier Anwendungen und ihre Datenbanken beteiligt sind. Die Entwicklung ist abgeschlossen, doch die Datenbankänderungen müssen noch zwischen mehreren Spezialisten abgestimmt und in passende Wartungsfenster eingeplant werden.
Ein Teil dieser Vorbereitung ist notwendig. Die entscheidende Frage ist, wie viel Zeit tatsächlich in die Risikobewertung fließt und wie viel in Abstimmung, Übergaben und Terminplanung.
Wenn jeder Release diesen Aufwand verursacht, liegt es nahe, mehrere Änderungen zu bündeln. Fertige Funktionen warten dann auf andere Arbeiten, und bei größeren Releases wird es schwieriger, Fehler schnell einzugrenzen. Kleinere Releases machen Probleme leichter nachvollziehbar und einfacher zu beheben.
Gleichzeitig verbringen erfahrene Datenbankspezialisten Zeit mit der Ausführung bereits freigegebener Skripte, statt sich mit Performance, Zuverlässigkeit oder Verbesserungen der Plattform zu beschäftigen.
Das wirkt sich auch auf die Planung aus. Ein Projekt kann laut Entwicklungsreport im Zeitplan liegen, während die Datenbankänderungen noch in einer eigenen Warteschlange stehen. Realistische Go-live-Termine müssen beides berücksichtigen.
Integrieren Sie die Datenbank in den Release-Prozess
Mit Redgate Flyway können Datenbankänderungen Teil desselben automatisierten Release-Prozesses werden wie Änderungen an der Anwendung. Teams speichern Änderungen als versionierte Skripte in der Versionsverwaltung. Flyway führt ausstehende Migrationen in der vorgesehenen Reihenfolge aus und dokumentiert pro Datenbank, welche Änderungen bereits angewendet wurden.
Datenbankspezialisten können Änderungen bereits während der Entwicklung prüfen. Die freigegebene Ausführung übernimmt anschließend die Pipeline. Probleme werden dadurch früher sichtbar und ein Deployment hängt nicht länger davon ab, dass jemand eine Reihe von Skripten manuell ausführt.
Teams, die GitHub einsetzen, sollten sich auch die Flyway Actions von Redgate ansehen. Sie wurden Anfang dieses Jahres veröffentlicht und bieten wiederverwendbare Schritte für die Prüfung und Bereitstellung von Datenbankänderungen.
Behalten Sie die Kontrolle über die Produktion
Flyway Enterprise kann unerwartete Änderungen an der Datenbankstruktur erkennen, zum Beispiel einen Notfall-Fix, der nie in den regulären Release-Prozess übernommen wurde. Eine entsprechend konfigurierte Pipeline kann das Deployment dann stoppen, damit die Abweichung zunächst geprüft wird.
Abhängig von Edition und Datenbankplattform bietet Flyway außerdem Vorschauen geplanter Änderungen sowie automatisierte Codeprüfungen. Reviewer erhalten damit vor der Freigabe einen besseren Einblick in das, was tatsächlich in Produktion geändert werden soll.
Bestehende Freigabeprozesse und Zugriffsbeschränkungen müssen dabei nicht entfallen. Legen Sie fest, wer Änderungen freigeben darf, wie Notfalländerungen dokumentiert werden und wo Freigaben und Deployment-Informationen aufbewahrt werden.
Große Datenmigrationen müssen weiterhin sorgfältig vorbereitet und getestet werden. Manche Änderungen benötigen auch weiterhin ein Wartungsfenster. Automatisierung ersetzt weder die Erfahrung der Datenbankspezialisten noch einen guten Recovery-Plan.
Beginnen Sie mit einer Anwendung
Starten Sie mit einer Anwendung, bei der Datenbankarbeit die Auslieferung regelmäßig verzögert. Bringen Sie Anwendungs- und Datenbankteam zusammen, um den aktuellen Stand festzuhalten, Unterschiede zwischen den Umgebungen zu beseitigen und die nächsten Änderungen über einen automatisierten Prozess auszurollen.
Messen Sie anschließend über mehrere Releases hinweg die Wartezeit, den manuellen Aufwand und fehlgeschlagene Deployments. Berücksichtigen Sie dabei auch Lizenz- und Einführungskosten. Entscheidend sind kürzere Wartezeiten und weniger manuelle Arbeit, ohne dass die Zahl der Störungen steigt.
Ein erstes Ergebnis kann bereits eine Routineänderung sein, die noch diese Woche in Produktion geht, statt auf das Wartungsfenster im nächsten Monat zu warten.
Masterminds ist seit vielen Jahren Redgate Gold Partner. Unsere DevOps- und Data-Teams arbeiten gemeinsam an der Bestandsaufnahme, der Automatisierung und den ersten Deployments, einschließlich der Review- und Ausnahmeprozesse, die Produktionsteams benötigen.
Vereinbaren Sie ein Gespräch, um einen kürzlich verzögerten Release gemeinsam zu betrachten und zu prüfen, wo Datenbankautomatisierung einen Unterschied gemacht hätte.
