Vielfach unterschätzt: DevOps & Konfigurationsmanagement

Die Tatsache, dass DevOps und CALMS-Prinzipien ihren Ursprung in der „agilen Szene“ haben, darf nicht darüber hinwegtäuschen, dass sich Continuous Delivery (CD) und DevOps auf Bereiche des IT Service Managements auswirken (z.B. Konfigurationsmanagement), die bislang am wenigsten nach agilen Prinzipien arbeiten.

Der Lebenszyklus einer Software hängt von der Infrastruktur und den Prozessen ab: Hardware (Server, Clients), Netzwerk-Administration und alle unterstützenden (ITIL®-) Prozesse – insbesondere des Konfigurationsmanagements (CM).

Die Continuous Delivery-Pipeline (CD-Pipeline) implementiert diese Infrastruktur, soweit möglich, in Form von Software und automatisiert die für das Deployment notwendigen Prozesse.

Dabei steht die CD-Pipeline aber nicht für sich alleine , sondern ist eng mit dem (CM) verzahnt. In ITIL® wird das CM durch den Prozess „Software Asset and Configuration Management“ (SACM) abgedeckt. Der gesamte Lebenszyklus einer Applikation ist untrennbar mit dem CM verbunden.

Übertragen auf den Software-Entwicklungs- und Lebenszyklus könnte man jetzt argumentieren, dass bei einer agilen Vorgehensweise auch kein vollständiges CM für das zu entwickelnde System von Anfang an vorhanden sein muss. Traditionell konzentrieren sich Software-Entwickler zumeist sowieso auf die Funktionalität, Inbetriebnahme und Konfigurationsmanagement werden somit bewusst oder unbewusst vernachlässigt.

Will man diesem Problem entgegentreten, stellt sich die Frage, ob und wie die CD-Pipeline und das CM von Anfang an in die Applikationsentwicklung miteinbezogen werden sollen.

Im günstigsten Fall, ist es möglich eine bereits vorhandene Infrastruktur (CD-Pipeline) samt deren Integration ins SACM zu nutzen. Sollte dies mit wenigen oder gar überhaupt keinen Anpassungen der CD-Pipeline möglich sein, sollte hinterfragt werden, ob für die Durchführung der Entwicklungsaktivitäten überhaupt ein eigenes Projekt notwendig ist.

Muss die CD-Pipeline und damit das SACM neu implementiert werden, stellt dies höhere Anforderungen für die neu zu erstellende Applikation und dessen Integration in bereits vorhandene CM -Strukturen.

Es gibt drei Varianten zur Implementierung der CD-Pipeline und des CM bei der Applikationsentwicklung:

Variante 1: Erstellung des Konfigurationsmanagement vor oder während der Arbeit am initialen Release / Prototyp

Parallel zum Aufbau eines Prototypen oder des ersten Releases wird das CM im Rahmend der CD-Pipeline aufgebaut. Beispielsweise wird das CM im Rahmen von Start-Up-Aktivitäten naturgemäß vernachlässigt, um die Time-to-Market-Zeitspanne möglichst klein zu halten.

Der einzige Nachteil dieser Vorgehensweise ist, dass Ressourcen für Infrastrukturautomatisierung eingesetzt werden und nicht dem Produkt an sich zugutekommen. Dem kann man entgegenhalten, dass selbst in cross-funktional aufgestellten Teams unterschiedliche Ressourcen für funktionale und Infrastrukturentwicklung zuständig sind.

Wird die Erstellung der automatisierten Infrastruktur gleich von Beginn an vorangetrieben, müssen eben alle Skills von Anfang am aufgebaut werden.
Ein weiterer Punkt ist, dass man eine Produkt/IT Service ohne hinreichendes CM nicht oder nicht kostendeckend betreiben kann. Somit fallen Kosten für die CM-Integration auf jeden Fall an. Und je später sie anfallen, desto größer ist das Risiko, das zuvor getroffenen Designentscheidungen die Aufwände für die CM-Integration in die Höhe treiben.

Ein weiteres Argument gegen die Implementierung der CD-Pipeline von Anfang an könnte das Nichtvorhandensein agiler Vorgehensweisen sein. Agil aufgestellte cross-funktionale Teams machen es leichter, DevOps-Engineers für die Implementierung des Konfigurationsmanagement und der CD-Pipeline in das Team zu integrieren.

Eine nicht-agile Vorgehensweise bei der Variante 1 ist dann akzeptabel, wenn die zu entwickelnden Systems ein sehr einfaches CM benötigen.
Beispielsweise kommt eine Micro-Service-Architektur in Verbindung mit einem einfachen Versionskontrolle einem schlanken CM entgegen. Allerdings macht es ein solches Szenario auch einfach, agile Vorgehensweisen einzuführen.

Variante 2: Erstellung des Konfigurationsmanagement nach dem ersten Release

Zunächst konzentriert sich das Entwickler-Team auf die Entwicklung des ersten Release oder Prototypen und erst danach auf den Aufbau der Infrastruktur für das CM . Wie bereits erwähnt, rückt das Konfigurationsmanagement oft erst dann in den Vordergrund, wenn ein Entwickler-Team kurz vor der Fertigstellung des initialen Releases steht.
Als Vorteil dieses Ansatzes erscheint es, dass sich die Entwickler zunächst auf das unmittelbare Ziel -die Markteinführung- konzentrieren können.
Andererseits kann ein Mangel an CM-Integration Auswirkungen auf nachfolgende Releases haben. Vor allem dann, wenn das erste Release „vor Kunde“ erfolgreich ist und sich dadurch der Druck des Marktes erhöht, ein zweites Release mit erweiterten Features oder Bug Fixes zu erstellen.
In so einem Fall könnte das Team um DevOps Engineers und CM-Spezialisten vergrößert werden, was aber auch keine sofortige Beschleunigung des Entwicklungsprozesses zur Folge hätte.

Das Antipattern für eine Vorgehensweise nach Variante 2 ist der Bau komplexer monolithischer Systeme in einem nichtagilen Umfeld. In derartigen Situationen stellt eine beschleunigte Markteinführung ohne hinreichendes CM einen Pyrrhussieg dar:
Die Lead Times für neue Releases würden immer Länger und die damit verbundenen Aufwände immer höher, bis es unwirtschaftlich wird, die Entwicklung eines solchen Produktes weiter zu betreiben.

Der agile Weg

Bei Agilität geht es um Priorisierung. Diese konzentriert sich auf die Einführung einzelner CM-Funktionalitäten mit hoher Priorität vor oder während Release 1 und konzentriert sich auf die Implementierung von CM-Funktionalitäten mit niedrigerer Priorität zu einem späteren Release.
Um das Projektrisiko zu reduzieren, kann es sinnvoll sein, wichtige CM-Elemente „Just-in-time“ zu implementieren. Dies setzt auf jeden Fall eine agile Vorgehensweise voraus.
Somit stellen sich die Herausforderungen der Varianten 1 & 2 erst gar nicht. Allerdings stellt die Einführung agiler Vorgehensweisen jede nicht-agile Organisation vor Herausforderungen.

Die Lösung um dieses Risiko abzuschwächen stellt der in „DevOps Strategies“ vorgestellte zweistufige Entwicklungsprozess „Unified Continuous Delivery“ dar (Fig. 1).

Figure 1.: UCD

Fig. 1

Die erste Stufe besteht aus einer relativ kurzen Projektphase, in der ein Prototyp oder ein erstes Release zusammen mit der CD- Pipeline implementiert wird. In dieser „Projektphase“ erfolgt auch bereits eine weitgehende Integration in das CM .
In der darauffolgenden Phase „Linienorganisation“ kann die weitere Implementierung innerhalb eines Projektes oder der Linienorganisation vorangetrieben werden.

Fazit

Die Verzahnung einer CD-Pipeline mit dem CM ist ein in vielen Projekten unterschätzter Aspekt und solle gleich von Anfang des Projektes mit der Implementierung der CD-Pipeline betrieben werden.
Obschon agile Vorgehensweise der optimale Weg wäre, kann in Verbindung mit dem in „DevOps Strategies“ beschriebenen UCD auch eine nichtagile Vorgehensweise zum Ziel führen, solange die Entwicklungsinkremente nicht zu groß sind.
Eine Organisation, die DevOps und Continuous Delivery etablieren möchte, sollte dies unter Anwendung agiler Vorgehensweisen tun. Selbst dann, wenn dies zu größeren kulturellen Verwerfungen und Widerständen innerhalb der Organisation führen sollte. In einem solchen Fall ist es ein vielversprechender Weg, im ersten Schritt ein nicht zu komplexes und eher nicht geschäftskritisches System mittels DevOps zu entwickeln.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.