vorheriger Artikel
Ein schlanker, nachhaltiger Deploymentprozess ist zentral für eine schnelle und integre Entwicklung. Im Vordergrund steht dabei die Stabilität und Qualität der Produktionsumgebung. Der Weg dahin kann einfach sein, jedoch wissen die meisten vor lauter Optionen und Möglichkeiten nicht, wie das Grundgerüst des Prozesses aussehen könnte. Im folgenden Blogbeitrag wird ein schlichter Deploymentprozess beschrieben, der beliebig erweiterbar ist und mit Hilfe von Best Practices im WhereScape-RED-Umfeld zum sicheren Erfolg führt.
Back to Basics: Deploymentgrundsätze
Das primäre Ziel eines Deploymentprozesses besteht darin, sicherzustellen, dass die Integrität der Produktionsumgebung geschützt wird und nur zuvor getestete Objekte auf dieser veröffentlicht werden.
Standardmäßig gelingt dies, indem man Objekte auf einer separierten Umgebung (DEV) entwickelt. Diese entwickelten Objekte werden dann auf einer weiteren Umgebung (TEST), die der Produktionsumgebung in vielen Punkten entspricht, ausführlich geprüft und anschließend auf dem eigentlich Ziel, der Produktionsumgebung, ausgerollt.
Im Vordergrund bei diesem Vorgehen steht dabei das Testen der zu veröffentlichenden Objekte. Dabei sollte jedes Deployment den Grundlagen des Testings (Vollständigkeit, Nachvollziehbarkeit und Wiederholbarkeit) entsprechen. Dies gilt natürlich sowohl für die Integrität der Objekte nach dem Deployment als auch für die inhaltliche Richtigkeit der Elemente.
Bei komplexen Landschaften im Data-Warehouse-Bereich gibt es oft auch eine weitere Instanz: die Integrationsumgebung. Diese dient als Konsolidierungsumgebung und wird meistens dazu gebraucht, ein Release auf technische Integrität bei Installation bzw. Rollout zu prüfen.
Skizzierung eines einfachen Deploymentprozesses
Die oben dargestellte Grafik zeigt einen simplen Deploymentprozess. Gestartet wird mit der Umsetzung einer Anforderung auf der Entwicklungsumgebung (DEV). Wenn ein:e Entwickler:in die Arbeit abgeschlossen hat, wird der Artefakt gegen die Integrationsumgebung getestet. Ist die Integrität gewahrt, folgt das Rollout auf die Testumgebung. Dort angekommen finden Reviews und User Acceptance Tests statt.
Müssen auf einer Ebene an dem Artefakt Änderungen vorgenommen werden, beginnt der Prozess auf der Entwicklungsumgebung von vorne. Ist das Artefakt erfolgreich auf den Umgebungen deployt worden, werden diese dem Release hinzugefügt. Das Release wiederum folgt in seiner Gesamtheit dem gleichen Zyklus und wird nach anschließender Freigabe auf der Produktionsumgebung (PROD) installiert.
Release-Zyklus
Bis man einen vollautomatisierten Prozess (CI/CD) entwickelt hat, empfiehlt es sich, Produktions-Rollouts in einer zyklischen Anordnung zu veröffentlichen. Dadurch lässt sich der Fortschritt planen und prüfen, was zu weiterer Transparenz in der Entwicklung führt.
Gleichzeitig lässt sich der Entwicklungs-Scope gut auf einen Zyklus zuschneiden, und Problematiken, wie das gleichzeitige Arbeiten an gemeinsamen Objekten, können reduziert werden. Die Länge eines Zyklus hängt natürlich von vielen Faktoren ab. Ein Ansatz ist es, sich an anderen Zyklen, wie zum Beispiel dem eines Sprints, zu orientieren.
Release-Management
Der Release- und Deploymentprozess gehört zu den wichtigsten Prozessen im Bereich des Data Warehouse Managements. Aus diesem Grund macht es Sinn, eine Instanz einzuführen, welche die Verantwortung für diesen Prozess übernimmt und sich gleichzeitig um weitere organisatorische Aufgaben im Rahmen des Releases kümmert. Diese Instanz wird als Release-Management bezeichnet und besteht aus mindestens zwei Personen. Dies wahrt das Vier-Augen-Prinzip und fördert die Review-Kultur bei dessen Aufgaben.
So sollte man zum Beispiel das Zusammenführen von „Feature-“ bzw. „Anforderungsbranch“ und „Release Branch“ nur über einen Pull Request tätigen können. Diesen Pull Request bestätigt dann das Release-Management und prüft zum Beispiel, ob eine Anforderung auch tatsächlich abgenommen und weitere organisatorische Punkte eingehalten wurden.
Natürlich hängt ein guter Deploymentprozess von vielen Faktoren ab und ist immer an die Gegebenheiten der System- und Unternehmenslandschaft gebunden. Klar ist auch, dass das Konzept in diesem Beitrag stark vereinfacht und simplifiziert dargestellt wird. Ein gut strukturierter, übersichtlicher Prozess trägt aber maßgeblich zu einer schnellen, konsistenten und transparenten Entwicklung bei. Er ist ein Eckpfeiler für gute Entwicklungsarbeit und eine geschützte Produktionsumgebung und verdient sich dadurch Deine Aufmerksamkeit.
Wenn Du erfahren möchtest, was es darüber hinaus im Zusammenhang mit WhereScape RED und dem Deploymentprozess zu beachten gilt, dann schau dir Teil 2 dieses Blogbeitrags an.
Rückrufservice