vorheriger Artikel
Nachdem wir im ersten Teil dieses Blogbeitrags über die Grundzüge eines simplen Deploymentprozesses gesprochen haben, möchte ich nun auf ein paar Punkte eingehen, die es im Zusammenhang mit WhereScape RED und dem Deploymentprozess zu beachten gilt.
Entwickeln im Team mit WhereScape RED
Generell fängt die Entwicklungsarbeit meist mit der Zuweisung einer Anforderung im Rahmen eines Tickets an. Es empfiehlt sich, den Anforderungsumfang, gemessen an den zu ändernden WhereScape-RED-Objekten, möglichst klein zu halten, da die Entwicklung in WhereScape RED einen gemeinsamen Objektpool nutzt. Das heißt: Je größer der Scope einer Anforderung ist, desto wahrscheinlicher ist es, dass mehrere Entwickler:innen die gleiche Schnittmenge an Objekten bearbeiten müssen. Natürlich gibt es hier Mittel und Wege, die dadurch aufkommenden Probleme zu lösen. Dies führt in der Regel aber zu Abhängigkeiten in der Entwicklung und letztendlich zu potenziell invaliden Objekten bei einem Deployment. WhereScape RED bietet einen einfachen und komfortablen Weg, sicherzustellen, dass an einem Objekt auch nur ein:e Entwickler:in arbeitet.
Die „Check Out“-Funktion (Rechtsklick auf das Objekt) ermöglicht es, dieses für alle weiteren Entwickler:innen erkennbar zu sperren, eine neue Version des Objektes zu erstellen und eine Dauer der Sperrung einzustellen. Gleichzeitig kann man im WhereScape Repository einen Grund für die Sperrung hinterlassen. Falls beispielsweise ein:e Entwickler:in unverhofft ausfällt und gesperrte Objekte zurücklässt, ist es so auch möglich, über das WhereScape Repository eine Entsperrung zu erzwingen.
Bei größeren Entwicklerteams, großen Anforderungen oder keiner entsprechenden Entwicklerrichtlinie sind Konflikte vorprogrammiert und invalide Objekte werden zwangsweise die Integrität der Umgebungen bei einem Deployment verletzen. Daher ist es unabdingbar, eine geeignete Entwicklerrichtlinie aufzusetzen und die zu veröffentlichenden Objekte durch Tests und Checks zu prüfen.
Das Release im WhereScape-RED-Kontext
Unter einem Release versteht man die zu veröffentlichenden Arbeitsergebnisse (Artefakte). Im Data-Warehouse-Bereich kann ein Artefakt das komplette Data Warehouse in einer neuen Version, ein einzelnes Objekt in einer neuen Version oder aber eine spezifische Teilmenge des Data Warehouses darstellen.
Es empfiehlt sich, WhereScape-RED-Deployments im Delta-Verfahren auszurollen. Das Release ergibt sich dann aus der Summe aller geänderten und neu erstellten Objekte. Der Umfang des Deployments wird hiermit auf das Minimum reduziert und man sichert sich weitere Vorteile:
- Schnelligkeit bei der Installation
- nicht geänderte Objekte werden auch nicht rekompiliert, was eine weitere Fehlerquelle ausschließt
- Log-Files sind minimiert und folglich ist der Zeitaufwand für Kontrolle und Prüfung des Deployments auch minimiert und übersichtlicher
Alternativ kann man über ein Full-Deployment oder ein Teilmengen-Deployment nachdenken. Allerdings bieten diese Möglichkeiten keinen ersichtlichen Mehrwert gegenüber einem Delta-Deployment. Natürlich hängt dies auch immer von den Gegebenheiten des Data Warehouses bzw. von den organisatorischen Strukturen ab. Allgemein gilt jedoch, dass durch die Minimierung der Größe des Releases die Komplexität im Deploymentprozess sinkt. Abhängigkeiten sind nachvollziehbarer, Fehler sind schneller erkennbar und die Länge eines Deployments wird auf ein Minimum reduziert. Wir erreichen hierdurch Transparenz, Schnelligkeit und Wartbarkeit.
Git im WhereScape-RED-Kontext
Tools wie Git dienen im eigentlichen Sinn der verteilten Versionsverwaltung. Eine WhereScape-Applikation besteht aus acht .wsl-Dateien. In diesen Dateien sind zwar die Metadaten enthalten, jedoch ist ein herkömmlicher Merge mit Git nicht möglich. Erstens werden die Metadaten nicht zwingend sortiert und zweitens sind spätestens durch ein Deltaverfahren die Inhalte der Dateien abhängig vom Deploymentumfang einer Anforderung. Aus diesen Gründen sollte man die Funktionen von Git nur in einer reduzierten Form verwenden. In unserem Umfeld können wir Git als synchronisierten Speicherort nutzen und die entwickelten WhereScape-Applikationen auf einfache Art und Weise auf die anderen Umgebungen transportieren.
Die Darstellung oben zeigt einen beispielhaften Prozessweg für die Entwicklung mit Git im Rahmen eines Deployments. Das Artefakt wird auf der DEV-Umgebung entwickelt und es wird lokal im Git Repository in einem „Feature“- oder „Anforderungsbranch“ abgelegt. Nach dem Hochladen („Push“) der Dateien auf den serverseitigen Branch ist es nun möglich, auf eine andere Umgebung zu wechseln und den Inhalt des Branches wieder herunterzuladen („Pull“). Dies erlaubt es, das Artefakt aus der Ordnerstruktur des Branches heraus zu installieren.
Da man für ein Release nicht immer alle relevanten Branches zusammensuchen und diese einzeln installieren möchte, bietet es sich an, die Artefakte nach ihrer erfolgreichen Abnahme in einem Branch zu sammeln, dem Release Branch. Der Release Branch wird im Rahmen von organisatorischen Aufgaben rund um ein Release vom Release-Management erzeugt. Die einzelnen „Feature“- oder „Anforderungsbranches“ müssen hierzu mit dem Release Branch zusammengeführt werden („Merge“). Der Inhalt dieses Branches ist folglich unser Release, eine Sammlung von WhereScape-Artefakten in einer Ordnerstruktur. Anschließend ist es üblich, den Release Branch mit dem Master Branch zusammenzuführen. Der Master Branch dient dabei als Single Point of Truth und ist mit einer guten Ordnerstruktur eine übersichtliche Quelle der Release-Historie.
Zusammengefasst hilft uns Git im Zusammenspiel mit WhereScape in folgenden Punkten:
- synchronisierter Speicherort für die Artefakte
- Transporthilfe für die Artefakte zwischen den Umgebungen
- Sammelpunkt für die verschiedenen Artefakte
- einfacher Zugang zu einer übersichtlichen Historie der Releases
Falls Du Interesse an weiteren Informationen hast oder Unterstützung bei Fragen rund um WhereScape, DWH-Automatisierung oder Deploy- und Integrationsvorgehen benötigst, komm gerne auf uns zu!
Du hast Teil 1 dieses Beitrags verpasst?
