Bimodales Release-Management gegen Reibungsverluste Wo liegen bei DevOps die Grenzen der Agilität?

Fällt das Wort DevOps, so wird per se davon ausgegangen, dass eine hochgradig automatisierte und standardisierte Software-Produktionsstraße existiert. Die Agilität der Software-Entwicklung und -Bereitstellung hängt aber noch von ganz anderen Faktoren ab.

DevOps wird immer wieder mit der Tatsache verbunden, dass Software-Änderungen auf schnellem Wege in die Produktion gelangen. In der Realität bestimmen aber zwei wesentliche Faktoren beziehungsweise Organisationseinheiten darüber, wie agil das Ganze abläuft: Der Fachbereich im Rahmen notwendiger Test und Freigaben sowie das Release Management zur Freigabe des Software-Releases.

Anhand dieser beiden Organisationseinheiten soll veranschaulicht dargestellt werden, wie deren Einbindung dafür sorgt, dass Release-Laufzeiten sich verlängern und damit die Grenzen der Agilität sprengen, so dass wieder die Laufzeiten der alten starren Planungswelt erreicht werden.

Der folgende Artikel beschreibt konkret, wie innovative Software-Produktionsstraßen beziehungsweise deren wesentlichen Elemente grundsätzlich funktionieren. Danach werfen wir einen Blick auf die wesentlichen Faktoren, welche die Agilität beeinflussen, um dann abschließend Ansätze zu formulieren, die dieses Problem lösen oder zumindest dämpfen.

Die innovative Software-Produktionsstraße

Die Softwareentwicklung ist agil und DevOps-Technologie mit hohem Automationsgrad etabliert. Es existiert keine organisatorische Trennung zwischen Dev (Entwicklung) und Ops (Betrieb).

Wesentlicher Ablauf:

• 1. Code-Übergabe durch den Entwickler in das Repository.

• 2. CI: Continuous-Integration-Prozess: kompilieren, Unit-Test, Code-Qualitätsprüfung, Artefakterstellung.

• 3. Automatische Bereitstellung der Entwicklungs- und Testumgebung durch ein DevOps-Team mittels IaC (Infrastructure as Code).

• 4. CD: Ausrollen der Anwendung auf die jeweilige Umgebung mittels Continuous Delivery.

• 5. Automatisierte Integrationstests der Stages. Die Entwicklungsumgebung wird ohne weitere Tests des Fachbereiches automatisch bereitgestellt.

• 6. Manuelle Fachtests und fachliche Abnahme der Testumgebung durch den Fachbereich. Nach Funktionstest und fachlicher Abnahme durch den Fachbereich ist die Testumgebung einsatzfähig.

• 7. Release-Management-Prozess zum Aufbau der produktionsnahen Umgebungen (Referenz und Produktion). Dieser Prozess ist erforderlich (analog zur klassischen Welt), um Abhängigkeiten zu anderen IT-Systemen zu prüfen.

• 8. Automatische Bereitstellung der Referenz- und Produktionsumgebung durch ein DevOps-Team mittels IaC.

• 9. CD: Ausrollen der Anwendung auf die jeweilige Umgebung mittels Continuous Delivery.

• 10. Automatisierte Integrationstests der Stages

• 11. Manuelle Fachtests und fachliche Abnahme der Referenz- und Produktionsumgebung durch den Fachbereich. Damit sind die produktionsnahen Umgebungen bereitgestellt.

Was begrenzt die Agilität?

In der vorangestellten Abbildung sind bezogen auf die beiden wesentlichen zeitlichen Parameter „Bereitstellungszeitraum“ und „Release-Zyklus“ die aus der Praxis ermittelten, durchschnittlichen Erfahrungswerte der Laufzeiten:

Bereitstellungszeitraum: Zeit für die Bereitstellung eines Stagings (Entwicklung, Test, Referenz und Produktion).

Release-Zyklus: Zeit für das Ausrollen einer SW-Änderung in die jeweilige Umgebung (Entwicklung, Test, Referenz und Produktion).

Die Laufzeiten für den Aufbau eines kompletten Stagings für alle vier Umgebungen liegen damit zwischen 12 und 21 Arbeitstagen. Ebenso wird eine SW-Änderung bis zur Produktion von circa vier bis sieben Tagen benötigt.

Bei genauerem Hinsehen erkennt man auf Basis der Erfahrungswerte sofort die beiden Problembereiche, welche die Agilität bremsen:

1) Fachliche Freigaben

Was in der Praxis zumeist nicht automatisiert wird, sind die Tests der Fachbereiche für die jeweiligen Stages (Test, Referenz, Produktion). Hier werden wesentliche, fachliche Funktionen durch die späteren Nutzer oder zumindest durch Personen mit Fachkenntnis getestet, damit der Code als „fachlich abgenommen“ gilt.

Bedingt durch Überlastung der Mitarbeiter und nicht optimalen Vertretungsregelungen können Fachfreigaben – sofern nicht mit entsprechendem Vorlauf geplant – mehrere Tage Verzögerung generieren (circa vier bis sieben Tage). Hierdurch wird die grundsätzliche Agilität der Infrastruktur gebremst, da die reine Bereitstellung (IaC, CD sowie Integrationstests) hochgradig automatisiert ist, die fachliche Freigabe jedoch nicht.

2) Release-Management

Das Release-Management ist in der Regel ein standardisierter und gelebter Prozess innerhalb der IT. Dieser stellt sicher, dass SW-Änderungen keine Auswirkungen auf Schnittstellen oder Dritt-Systeme innerhalb der IT-Landschaft haben. Genau hier ist das Problem. Sofern keine Abhängigkeiten existieren, kann quasi jederzeit ein SW-Release ausgerollt werden.

Bestehen aber Abhängigkeiten zu nicht-agilen IT-Systemen (also zum Beispiel schwergewichtige Backends oder Hosts), richten sich die Release-Zeiten nach der Taktung dieser Systeme. In der Praxis wird dies für einen Major/Minor-Release bis zu drei Monate dauern. Was das dann für den Agilitätsgedanken heißt, ist klar. Die Agilität folgt den klassischen Laufzeiten einer Software-Produktionsstraße, wenn Abhängigkeiten zu nicht-agilen IT-Systemen existieren.

Lösungsansätze

Testautomatisierung der fachlichen Freigaben

Um die höheren Laufzeiten der manuellen Freigaben durch die Fachbereiche zu beschleunigen, ist die Antwort recht einfach: „Automatisiere alles“. Das heißt, dass die in der Regel überschaubaren Testfälle der Fachbereiche automatisiert werden. Hier gibt es generell zwei Bereiche zu betrachten:

• 1. GUI-Tests: Für den Test von Oberflächen können Testwerkzeuge verwendet werden die sich auf Oberflächentests spezialisiert haben. Hiermit können einfache Funktionen komplett automatisiert werden.

• 2. Schnittstellen-Tests: Das Testen einer Schnittstelle erfordert im Gegensatz zu einer reinen GUI einen größeren Vorbereitungs- und Testaufwand. Dies gilt vor allem für den Fall, dass externe Schnittstellensysteme genutzt werden müssen.
  Hier müssen ebenso im Vorfeld der Release-Planung entsprechende Maßnahmen geplant beziehungsweise berücksichtigt werden. In der Realität beginnen hier schon die Herausforderungen, da zum Beispiel keine Testschnittstellen für alle Umsysteme (klassische Backends wie Hostsysteme, ERP und Bestandssysteme) existieren, sondern lediglich „produktive“. Hier wird in der Praxis wie folgt verfahren:
  a. Produktive Schnittstelle darf „lesend“ genutzt werden
  b. Produktive Schnittstelle besitzt einen Testmandanten der auch schreibend verwendet werden darf (dies ist keine ideale Lösung, jedoch nicht anders machbar)
  c. Bei Output-Relevanten Schnittstellen die beispielsweise Drucksysteme ansteuern, ist sicherzustellen, dass keine wirklichen Objekte gedruckt werden, sondern lediglich elektronische Abbilder wie PDF verwendet werden.

Die obigen Punkte beziehen sich darauf, dass die Schnittstelle der Servicegeber (Datenquelle) und das eigene System der Servicenehmer (Datennutzer) ist. Wenn sich das Konstrukt umdreht, ist ein Schnittstellentest in der Regel einfacher, da hier auch mit „Offline-Daten“ gearbeitet werden kann. Das heißt, dass ein vordefinierter Testdatensatz in das zu testende System übertragen und das Ergebnis überprüft wird (wie Übertragung von Stammdaten oder Bestandsdaten). Diese Überprüfung kann gegebenenfalls auch manuell erfolgen.

Automatisierte Bereitstellung von Testsystemen und Testdaten

Neben dem reinen Automatisieren des Tests wurde zwischen den Zeilen schon das Thema Testmandant und Testdaten erwähnt. Die beste Testautomatisierung und Code-Abdeckung nutzt nichts, wenn Nutzer und Daten für den Testfall entweder gar nicht oder nur teilweise existieren.

Für die Durchführung von Fachtest ist ebenso eine automatisierte Bereitstellung eines Testsystems mit den dazu erforderlichen Testdaten und Accounts wesentlich, damit ein Fachtest automatisierbar ist. Dies bildet somit eine wesentliche Grundlage für dessen Umsetzung.

Diese Abbildung zeigt die wesentliche Struktur der Testautomatisierung sowie kommerzielle oder freie Testwerkzeuge. Zu beachten ist noch die „manuelle“ Darstellung des Entwicklers für das Generieren der Testdaten. Im Idealzustand ist alles automatisiert. In der Praxis wird jedoch meist manuell bei der Generierung von Testdaten gearbeitet, die durch die Entwicklung bereitgestellt werden. Eine Lösung wäre hier eine zentrale Anforderung zur Erstellung von Werkzeugen zur Testdatengenerierung bei der Anwendungsentwicklung.

Einführung eines bimodalen Release-Managements

Das mit Abstand größte Problem ist die Einbindung beziehungsweise Berücksichtigung des Release-Managements im Kontext einer innovativen Software-Produktionsstraße, da hier die größten Laufzeiten (Abb.1) entstehen, wenn Abhängigkeiten zu anderen Systemen existieren. Dies liegt an der Aufgabe des Release-Managements, eine Software-Änderung und deren Abhängigkeiten zu anderen Systemen zu prüfen und Inkompatibilitäten auszuschließen. Die Abstimmungsaufwände gerade in Konzernstrukturen betragen dabei bis zu einem Quartal.

Der Schlüssel zur Bimodalität ist die Verbindung der „klassischen“ mit der „agilen“ Welt über das Release-Management. Hier ist eine Anpassung des Release-Management-Prozesses erforderlich, welcher in Abb. 3 grundsätzlich dargestellt ist. Dargestellt sind dort:

• die wesentlichen IT-Systeme, relevante Personengruppen beziehungsweise Organisationseinheiten

• eine Übersicht wesentlicher Werkzeuge oder Technologien:
     • aktuelle Frameworks
     • ITSM-Produkte
     • Backend-Produkte

• geschätzte Laufzeiten pro Release-Gruppe (siehe Erklärung unten)

• die agile Welt: Hier fokussieren sich Frontend-Anwendungen auf Basis leichtgewichtiger Architekturen bestehend aus Microservices und/oder Container-Technologien. Diese Anwendungen haben keine Abhängigkeiten zu anderen Systemen. Prozesse werden auf mehrere Funktionen verteilt.

• die klassische Welt: Hier geht es um sogenannte Backend-Systeme wie Host, ERP oder Bestandssysteme. Diese Anwendungen haben Abhängigkeiten zu anderen IT-Systemen und sind von ihrer Architektur monolithisch aufgebaut (ein Prozess enthält alle Funktionen).

Das ITSM-Tool als Dreh- und Angelpunkt der Bimodalität

Die Basis einer solchen Implementierung bildet das im Unternehmen eingesetzte ITSM-Tool. Hier werden alle Aktivitäten rund um Incident, Problem und Change gebündelt. Im Kontext eines Releases existieren dabei die üblichen Release-Typen:

• Minor-Change: Kleine SW-Änderung im Kontext Feature, Funktion, Sicherheit

• Major-Change: Umfangreiche SW-Änderung im Kontext Feature, Funktion, Sicherheit

• Hotfix: SW-Änderung zur Vermeidung kritischer Zustände (zum Beispiel Security Patches)

• Emergency: Notfall – Softwareänderung muss schnellst möglich (in der Regel ohne Prozess) ausgerollt werden.

Zur Verbindung beider Welten muss nun eine Release-Gruppierung dieser Release-Typen erfolgen (in folgender „Release-Gruppe“ genannt):

• 1. „Release-Gruppe-Klassisch“ oder „klassisches Release“: Folgt der alten Welt und deren Bereitstellungsprozesse und Zeiten. Es existieren Abhängigkeiten zu anderen Systemen.

• 2. „Release-Gruppe-Agil“ oder „agiles Release“: Folgt der agilen Welt. Keine Abhängigkeiten zu anderen Systemen.

Grundsätzlicher Ablauf des bimodalen Release-Managements

Die Integration beziehungsweise Umstellung auf Bimodalität soll minimalinvasiv ablaufen. Daher sollen möglichst alle existierenden Prozesse so weit wie möglich übernommen werden und nur notwendige Erweiterungen vorgenommen werden:

• 1. Alle Change-Aktivitäten werden wie gewohnt im Change Advisory Board analysiert, bewertet und priorisiert.

• 2. Eine notwendige Erweiterung zum vorherigen Prozess ist die Einstufung des Change in die jeweilige Release-Gruppe. Hier wird ermittelt beziehungsweise verifiziert, dass der Release-Typ entweder als agiler oder klassischer Release eingestuft wird.

• 3. Durch die Release-Gruppe erfolgt nun eine Zuweisung in eine schnelle oder langsamere Welt:
  a. Release-Gruppe-Agil: Hier kann mit deutlich kürzeren Vorlaufzeiten ein Change ausgerollt werden.
  b. Release-Gruppe-Klassisch: An dieser Stelle wird die agile Welt verlassen und dem Wasserfall gefolgt. Dies resultiert in deutlich höhere Laufzeiten der Changes.

• 4. Die Laufzeiten der Release-Typen Emergency und Hotfix differieren kaum zwischen beiden Welten, was in der Regel damit zu tun hat, dass hier die klassischen Prozesse aufgrund der Kritikalität in der Regel ausgesetzt werden.

Zusammenfassung und Ausblick

Die hier aufgezeigten Ansätze lassen sich in der Praxis gut implementieren, da der Status-quo kaum differiert, sofern ein ITSM-Tool verwendet wird. Die detaillierte Ausprägung der Abläufe mag dabei dann wiederum unternehmensspezifisch sein.

Die Herausforderungen eines bimodalen Release-Managements liegen weniger in der Prozesserweiterung und der Hinzunahme eines agilen Wertebegriffes, sondern eher in der Umsetzung eines hochautomatisierten Testmanagements mit adäquater Testabdeckung. Dazu zählt auch die automatisierte Bereitstellung von Testsystemen und Testdaten.

Die Bimodale IT an sich ist nur ein Zwischenschritt auf dem Weg zu einer vollumfänglichen digitalen Transformation der IT. Die agilen Werte sind dabei Bestandteil einer disruptiven Innovation, die dazu führt, dass mittel- bis langfristig alle klassischen Vorgehensmodelle und darin enthaltenen Technologien verschwinden werden.

* Gerd Herbertz, Jahrgang 1969, ist ausgebildeter Dipl.-Ing. (FH) Elektrotechnik. Bei adesso verantwortet er im Geschäftsfeld IT-Management Consulting das Competence Center Infrastruktur & Technologie, welches sich mit den Technologiestacks Microsoft und Linux beschäftigt. Speziell im Linux-Umfeld liegt der Fokus auf Konzeption, Aufbau und Übergabe von DevOps-Umgebungen im Rahmen von Kundenprojekten. Neben dem reinen Engineering und der Technologieberatung wird das Portfolio des Competence Centers durch IT-Management- und Strategieberatung abgerundet.

(ID:46413787)