Der Anwendungsfall
Herr Schulze, Business Analyst bei der Muster AG, hat das Datenmodell des DWH’s (Data Warehouses) angepasst, die Berechnung einer neuen Kennziffer implementiert und dies mit den Testdaten in der Entwicklungsumgebung erfolgreich getestet.
Wie bekommt er nun seine Änderungen in das produktive System?
Im traditionellen Vorgehen werden seine Änderung für das nächste monatliche Produktionsrelease eingeplant und das Releasevorgehen mit anderen Änderungen, dem Test- und Produktionsteam sowie der Fachabteilung abgestimmt.
Mit dem DataVault-Generator (DVG) von crossnative ist die Produktivnahme von Änderungen viel einfacher. Herr Schulze muss nur Folgendes tun:
- seine Änderungen im zentralen Git Repository, welches zur Verwaltung der DWH-Versionen genutzt wird, veröffentlichen
- einen Merge-Request stellen, den er Herrn Müller zur QS zuordnet
Dazu benötigt er nur 1 Minute Arbeitszeit.
Git schickt jetzt eine automatische E-Mail an Herrn Müller, die ihn über den gestellten Merge-Request informiert. Herr Müller weiß daher, dass er sich am Nachmittag eine halbe Stunde Zeit für die Abnahme nehmen muss.
Zusätzlich startet Git eine Pipeline, welche Folgendes tut:
- zero copy cloning
Zuerst wird vom produktiven DWH (Blue Umgebung) mit Hilfe des Zero Copy Clonings von Snowflake eine Kopie (Green Umgebung) erstellt. Diese Kopie ist vollständig identisch zur Produktion (Daten, Strukturen, Rechte, Ladeprogramme). Da nur Metadaten kopiert werden, fallen dafür keine zusätzlichen Speicherkosten an. - Migration
Auf der Green-Umgebung werden die vom DVG generierten Migrationsskripte ausgeführt. Dabei wird die Struktur des Datenmodells (neue/geänderte Felder und Tabellen) und die Ladeprogramme angepasst. Gleichzeitig erhalten aber auch alle Ladeprogramme, die direkt oder indirekt an der Berechnung der neuen Kennziffer beteiligt sind, die neue Versionsnummer. Diese Prozesse „wissen“ jetzt, dass sie bei der nächsten Beladung nicht nur Deltadaten verarbeiten müssen. Sie berechnen die neue Kennziffer fachlich rückwirkend für die gesamte im DWH vorhandenen fachliche Historie, ohne dass sich Herr Schulze darum kümmern muss. - Simulation
In der Green-Umgebung wird ein Simulationslauf gestartet. Dieser legt seine Ergebnisse im DWH so ab, dass er „normale“ Abfragen nicht beeinflusst, aber mit gezielten Abfragen auswertbar ist. Möglich macht dies die bitemporale Historie im DVG. - automatischer Vergleich
Die Ergebnisse des Simulationslaufes in der Green-Umgebung werden für alle Tabellen, Felder und Datensätze mit dem entsprechenden Produktionslauf, der noch in der alten kopierten Blue-Umgebung erfolgte, verglichen. Alle Abweichungen werden auf Tabellen-, Feld- und Datensatzebene protokolliert. Da der „alte“ Produktionslauf und die „neue“ Simulation auf den exakt gleichen Ausgangsdaten erfolgten sind alle gefundenen Abweichungen auf die Anpassung von Herrn Schulze zurückzuführen. - Abnahme
Herr Müller prüft die gefundenen Abweichungen. Da es ausschließlich Änderungen in den neu angelegten Feldern gibt, kann Herr Müller unerwartete Seiteneffekte sofort ausschließen. Er muss nur noch prüfen, ob die neue Kennziffer richtig berechnet wurde. Nachdem er sich davon überzeugt hat, erteilt er die Abnahme, indem er den Merge-Request genehmigt.
Hinweis:
Bis zu diesem Zeitpunkt erfolgten keinerlei Änderungen an der produktiven Umgebung. Wenn Herr Müller den Merge-Request nicht genehmigt, läuft die Produktionsumgebung ohne jegliche Anpassung und Risiko unverändert weiter. - Produktivnahme
Durch den genehmigten Merge-Request wird in Git eine weitere Pipeline gestartet. Diese tauscht die Green- und Blue-Umgebung mit Hilfe eines Swap-Befehls aus. Dies dauert nur wenige Sekunden. Danach ist die Änderung von Herrn Schulze produktiv.
Fazit
Mit Hilfe des DVG und der Git-basierten Automatismen aus der Softwareentwicklung können Änderungen sehr schnell und risikolos produktiv genommen werden. Dies unterstützt ein agiles Projektvorgehen mit häufigen Produktivnahmen ideal.
Das lange Warten auf das nächste Release gehört damit der Vergangenheit an.
