Software-Auslieferungsprozess beherrschen, Teil 1 Vom YAML-Modell zur Aktivitätenliste

IT-Systeme und ihre Auslieferungsprozesse werden immer komplexer. Ein modellgetriebener Ansatz hilft, die Methodik im Auslieferungsprozess zu verbessern. Qualität und Durchsatz werden dabei signifikant erhöht, IT-Mitarbeiter im operativen Alltag entlastet und somit auch die Kosten dauerhaft gesenkt.

Im Auslieferungsprozess aka Release Management geht es darum, neue Features oder Hotfixes über mehrere Stages bis in die Produktion zu bringen. Der Weg unterscheidet sich dabei in der Regel etwas.

Während ein Feature typischerweise über mehrere Umgebungen wie z.B. Integrationstestumgebung, Fachbereichsumgebung und eine produktionsähnliche Abnahmeumgebung mit den dazu charakteristischen Tests in die Produktion gelangt, wird bei Hotfixes der Weg bis in die Produktion eher über eine Hotfix-Umgebung abgekürzt, vor allem dann, wenn es „brennt“ und schnell gehen soll.

Bei verteilten und damit komplexen IT-Systemen sind jedoch je nach Änderung verschiedene Komponenten mit unterschiedlichen Auslieferungsaspekten wie z.B. ein neues Deployment-Artefakt, eine angepasste Konfiguration oder eine Datenbank-Änderung betroffen.

Das vorangestellte Bild skizziert zu dieser Problematik beispielhaft ein verteiltes IT-System mit unterschiedlichen Komponenten. In dem Bild sind Programme von unterschiedlichem Typ zu erkennen: z.B. Windows-EXE oder Application Server-EAR.

Die Programme benutzen unterschiedliche Services: Ein eigener Web-Service oder auch synchrone Adapter auf einer Integrationsplattform für die Anbindung an zentrale Domänenservices, die in diesem Szenario außerhalb des betrachteten Zuständigkeitsbereiches liegen sollen. Das IT-System besteht damit aus insgesamt 6 Komponenten (Instanzen), die 4 unterschiedlichen Komponententypen (Klassifikationen) zugeordnet werden können: EAR, EXE, Mule-Adapter und Spring-Boot

Anforderungen im Auslieferungsprozess

Unterschiedliche Umgebungen, Komponenten und deren Auslieferungsaspekte führen je nach Charakter eines Release zu einer gewissen Dynamik im Auslieferungsprozess. In der Praxis müssen je nach Umgebung unterschiedliche Aktivitäten für die Komponente, aber auch für die jeweilige Umgebung allgemeine, Komponenten-übergreifende, insbesondere vorbereitende und nachbereitende Aktivitäten durchgeführt werden.

Zur Einstimmung auf diese Problematik soll ein einfaches Beispiel dienen: Ein neues Feature soll für die Bestückung einer Fachbereichsumgebung bereitgestellt werden. Betroffen sei eine Programmkomponente Program1 und ein Adapter AdapterA für die Anbindung an einen Domänenservice. Die Fachbereichstests werden dabei delegiert. Ein einfacher Aktivitätenplan könnte dann so aussehen:

In der Praxis wird ein solcher Aktivitätenplan häufig manuell ggf. basierend auf alten Plänen neu zusammengestellt. In der Praxis ist dieses Vorgehen aufwändig und fehleranfällig. Zur Verbesserung der Methodik im Releasemanagement soll nun eine solche Aktivitätenliste über alle Umgebungen, den betroffenen Komponenten und deren konkreten Auslieferungsaspekten modellgetrieben erstellt werden.

Der erste Teil der Artikelserie betrachtet zunächst das grundlegende Konzept mit seinem generativen Ansatz basierend auf einfachen Modelldateien und zeigt die einfache Ergebnisoption „Check-Liste“. Der zweite Teil der Artikelserie erweitert das Konzept auf Continuous Delivery am Beispiel von GitHub-Actions und zeigt, wie die Aktivitäten auch automatisiert ausgeführt werden können.

Funktionsweise der Generierung

Durch den generativen Ansatz basierend auf den in YAML-Syntax formulierten Modelldateien, einem Template und einer Template-Engine lässt sich zu einem konkreten Release der dazu passende Auslieferungsplan generieren. Dies erfolgt zunächst in Form einer CSV-Datei, die später mit einem Tabellenkalkulationsprogramm noch optisch aufbereitet werden kann. Das Referenz-Projekt delivery-master dazu findet sich bei GitHub.

Dabei werden zu einem konkreten Release die benötigten Umgebungen und die Komponenten samt ihrer Auslieferungsaspekte in der Datei release.yml (das Instanzmodell) angegeben. Das Modell mit den umgebungsspezifischen und den komponentenspezifischen Aktivitäten befindet sich in der Datei activities.yml (das Klassifikationsmodell). Die Angaben hier basieren auf den Erfahrungen im Auslieferungsprozess und auf der Charakteristik der System-Infrastruktur, den Umgebungen und den Komponententypen.

Die Trennung des Modells in unterschiedliche Dateien erfolgt dabei bewusst nach dem Prinzip „Separation of Concerns“ und muss nur aus technischen Gründen vor der Generierung mit der Template-Engine FreeMarker wieder als ein Modell in der Datei model.yml zusammengeführt werden.

In der Praxis stabilisieren sich nach einer gewissen Zeit die eher technischen Angaben in der Datei activities.yml zur Beschreibung der IT-Infrastruktur. Im operativen Geschäft wird sich der Fokus bei immer wieder neuen individuellen Auslieferungen dann mehr und mehr auf die konkreten Angaben in der Datei release.yml richten.

In dem Referenzprojekt delivery-master erfolgt die Generierung dann einfach über den folgenden Maven-Befehl:

Dieses Bild zeigt einen (kleinen) Ausschnitt aus der beispielhaft generierten, dann aufbereiteten Aktivitätenliste. In dem Bild sind ausschnittsweise die letzten Aktivitäten einer Bestückung für die Vorproduktionsumgebung und die ersten für die Produktion zu erkennen.

Definition der Modelle in einfacher YAML-Notation

In dem Release (Datei release.yml) findet sich die Definition der benötigten Umgebungen, Rollen und Komponenten:

Das Beispiel demonstriert ein Feature, welches über eine Integrationstest-, Fachbereichs- und Vorproduktionsumgebung bis hin zur Produktion ausgeliefert werden soll. Die in den Aktivitäten verwendeten Rollen werden hier konkret für die Auslieferung besetzt.

Unter den Komponenten finden sich ein Programm und ein Adapter mit unterschiedlichen Auslieferungsaspekten (im Attribut tags). Über die Aspekte (tags) und den Komponententyp (componentType) können die release-relevanten Komponentenaktivitäten (activities) später in dem Klassifikationsmodell, in der Datei activities.yml, identifiziert werden. Beispiel einer solchen Modelldatei:

Der Auszug zeigt die Definition von typischen Aktivitäten zu den unterschiedlichen Auslieferungsaspekten (Konfiguration, DB-Änderung mit Flyway, Deployment). Die Zeitangaben lassen sich später in einem Tabellenkalkulationsprogramm in Verbindung mit der Summenfunktion dafür nutzen, auch den Zeitrahmen der Auslieferungsaktivitäten besser abzuschätzen.

Über die Rolle (Attribut role) können im Release (Datei release.yml) definierte Personen für die Ausübung der einzelnen Aktivitäten konkret zugeordnet werden. Das Attribut execution wird erst im zweiten Teil der Artikelserie verwendet, wenn es darum geht, die Aktivitäten mit GitHub Actions zu automatisieren.

Das folgende Beispiel zeigt eine der typischen, vorbereitenden Aktivitäten für alle angegebenen Umgebungen unter dem Attribut envs.

In analoger Art und Weise werden auch die nachbereitenden Aktivitäten modelliert.

Relationen im Modell und Auswertung im Template

Das Diagramm vorne zeigt die Relationen des Modells in UML-Notation. Die im obigen Diagramm dargestellten Relationen korrepondieren mit der Auswertung des Modells in der Templatedatei. Das (rot eingefärbte) Release als Oberbegriff bedient sich der blauen Klassen des Instanzmodells (release.yml).

Die grünen Klassen gehören zur Klassifikation der IT-Infrastruktur (activities.yml). Das Template soll an dem folgenden Fragment nur ansatzweise und kurz besprochen werden. Für weitere Details wird auf die FreeMarker-Website verwiesen.

Der Auszug aus dem Template zeigt die Erzeugung der Spaltenüberschrift, die Iteration über alle Umgebungen und die Ausgabe der vorbereitenden Aktivitäten über die eingangs definierte Template-Function lineStr, die sowohl Rollen als auch Hinweistext als optional betrachtet. Das Modell und auch das Template können natürlich leicht an die eigenen Bedürfnisse angepasst werden.

Fazit

Der Artikel hat gezeigt, wie die gesammelten Erfahrungen im Auslieferungsprozess genutzt werden können, um automatisiert und reproduzierbar die notwendigen Aktivitäten als Auslieferungsplan generieren zu lassen. Dabei ging es in erster Linie nicht um die Vorstellung eines fertigen Produkts, sondern vielmehr um die Idee, die sich mit dem gezeigten, recht einfachen und kostenlosen Tool-Stack individuell adaptieren lässt.

Als Ausgangsbasis kann dabei das GitHub-Referenzprojekt dienen. Bei der Berücksichtigung diverser umgebungsspezifischer Aktivitäten je Umgebung, den aspektorientierten Aktivitäten verschiedener Komponententypen inklusiver weiterer Prüf- und Testaktivitäten können schon bei einem mittleren System leicht einige hundert Aktivitäten in einem Auslieferungsplan zusammenkommen, der sich über diesen Ansatz einfach und sicher generieren lässt.

Auch wenn in den Beispielen dieses Artikels nur typische Online-Komponenten betrachtet wurden, können doch in analoger Weise auch alle möglichen anderen Komponenten wie z.B. Batch-Komponenten mit Jobketten/Workflows oder Batch-Programme mit in die Betrachtung einbezogen werden. Auch dazu finden sich Beispiele in dem GitHub-Referenzprojekt.

Ausblick

Im zweiten Teil dieser Artikelserie wird das Konzept auf Continuous Delivery am Beispiel von GitHub-Actions übertragen und die Aktivitäten werden dann automatisiert ausgeführt. Mit einem entsprechenden Adapter wäre auch eine Verbindung zu einem Change-Management-Tool möglich, um so den Anforderungen einer dem Release Management benachbarten Disziplin wie dem Change-Management-Prozess einfacher nachkommen zu können.

Changes und deren Aktivitäten werden dann auf Basis des Modells automatisiert erstellt. In der Kombination mit Continuous Delivery, wie dies im zweiten Teil der Artikelserie gezeigt wird, wäre auch gleich die Protokollierung der automatisiert angelegten Aktivitäten möglich.

* Jürgen Kürpig ist Software Architect bei adesso insurance solutions und unterstützt seit vielen Jahren java-basierte IT-Projekte in unterschiedlichen Rollen in den Themengebieten Architektur, Integration, Konzepterstellung und Projektmethodik.

(ID:48237991)