Die Software-Fabrik wird wahr

Die Software-Produktionsstraße

DevOps in Verbindung mit Continuous Delivery verspricht nicht weniger als die Realisierung der Software-Fabrik. Dabei hat es das Management in der Hand, ein solches Unterfangen die angemessenen Voraussetzungen für eine Realisierung zu schaffen – oder eben den Weg zum Scheitern zu bereiten.

Ein kurzer historischer Abriss – wie es nicht funktioniert

Das Versprechen der Software Factory ist keinesfalls neu. Seit den Anfängen der Software-Entwicklung gab es Bestrebungen, den Softwareentwicklungsprozess zu rationalisieren. Ziel war -und ist- die Plan und Quantifizierbarkeit der Entwicklungsaufwände sowie die Steigerung der Entwicklungsgeschwindigkeit (siehe auch DevOps Strategies).

Misslungene Ansätze, Rationalisierung flächendeckend in der Software-Industrie sind:

  • Wiederverwertung von bereits speziell angefertigten Komponenten oder zugekauften Standard-Komponenten. Zugegebenermaßen ist diese Technik heute grundlegende Voraussetzung jeder kommerzieller Softwareentwicklung – die Softwarefabrik hat sie aber nicht ermöglicht.
    Ein Grund hierfür ist, dass viele Software-Entwicklungen zurecht ein Projekt darstellen; innerhalb eines begrenzten Zeitraums wird etwas neues geschaffen, das Abteilungsübergreifende Anstrengungen notwendig macht. Es versteht sich fast von selbst, dass sich derartige Projekte in den meisten Fällen nicht alleine durch das Zusammenstecken von Standardkomponenten realisieren lassen.
  • Ein anderer felggeschlagener Versuch, die Software-Entwicklung zu rationalisieren bestand im Einsatz des Computer Aided Software Engineering (CASE). CASE beinhaltet die automatisierte Erzeugung von Programmcode durch den Einsatz grafischer Werkzeuge, die vom eigentlichen Quellcode abstrahieren. Einer der Gründe warum sich Case-Tools sich nicht durchgesetzt haben, sind:
    • Die Tatsache, dass die Komplexität durch das Case Tool nur oberflächlich überdeckt wird und der Entwickler sich fast immer auf die Code-Ebene begeben muss, wodurch CASE-Modellierung und Quellcode auseinanderlaufen. Deshalb haben sich nach der Erfahrung des Autors CASE-Tools nur in Nischenbereichen langfristig durchgesetzt .
  • Ein weiterer Ansatz, Model Driven Architecture (MDA), erfreut sich durchaus einiger Beliebtheit  – dies liegt daran, dass eine sorgfältige Modellierung der Architektur immer einer erfolgreichen Implementierung zuträglich ist. Allerdings ist MDA, wie CASE auch, wenig effizient bei heterogenen IT-Landschaften und damit verbunden ebenso heterogenen Architekturansätzen. Ähnlich wie CASE wird MDA von den Entwicklern aufgrund des zusätzlichen Abstraktionslevels und des damit verbunden Overheads als Hemmschuh bei der Entwicklung einfacher Komponenten wahrgenommen.

Wie es funktionieren kann

DevOps in Verbindung mit Continuous Delivery ist angetreten, dieses Versprechen einzulösen – allerdings mit einem völlig gegenteiligen Ansatz (DevOps Strategies) .

Zum Prinzip einer mittels DevOps und Continuous Delivery realisierten Software Factory passt das folgende Albert Einstein zugeschriebene Zitat:

Man sollte alles so einfach wie möglich machen, aber nicht einfacher

(Albert Einstein)

Es wird nicht versucht, die Entwickler von der Komplexität des Quellcodes abzuschirmen – stattdessen werden die folgenden Ansätze verfolgt:

  1. Es wird eine DevOps-Kultur nach den CALMS-Grundsätzen (DevOps Strategies) etabliert. Dies soll das entsprechende Mind Set in der Organisation verankern, z.B. dass der Programmcode nicht einzelnen Programmierern „gehört“, was eine neue Form von Verantwortungsbewustsein erfordert.
  2. Die agilen Prozesse werden so einfach wie möglich gestaltet und organisiert (z.B. Lean Management).
  3. Es wird in modularisierten Systemen gedacht und konzipiert (z.B. Micro Services).
  4. Es wird in kleinen Inkrementen gearbeitet, d.h. es werden Releases in kurzen Abständen ausgerollt. D.h. die Änderungen zwischen nacheinander ausgerollten Releases ist relativ klein und somit in vielen Fällen mehr oder weniger unkompliziert.
  5. Automatisierung. Alle die von Entwicklern und Admins routinemäßig ausgeführten Schritte wie das Bauen und Verteilen der Softwarepakete sowie, soweit möglich, auch das Testen werden automatisiert ausgeführt.

Kleinere Firmen, die mit einem neuen Produkt an den Start gehen, sind um Längen besser aufgestellt als große Firmen, die entweder:

  • Komplexe Produkte neu entwickeln und betreiben möchten oder
  • Existierende komplexe Produkte ersetzen möchten

Es ist für kleine Firmen viel leichter ein Micro Service-Architektur zu konzipieren, zu entwickeln und direkt vor Kunde auszurollen. Das kann im Extremfall sogar ohne zwischengeschaltete Testabteilung geschehen, wenn:

  • Es zwischen Kunde und Entwicklung eine hinreichend kurze Feedback-Loop existiert
  • Die Inkremente, d.h. Schritte zwischen den Releases hinreichend klein und überschaubar sind
  • Keine SLAs gegenüber Kunden einzuhalten sind
  • Für die Durchführung derartig kleiner Entwicklungsschritte, wie oben beschrieben, bietet sich die agile Entwicklungsweise an.

Im Gegensatz hierzu stellt der Aufbau einer Continuous Delivery-Pipeline im Rahmen eine DevOps-Einführung für komplexe Produkte eine finanzielle und organisatorische Herausforderung dar (DevOps Strategies):

  • Bestehende Prozesses und die Unternehmenskultur müssen umgebaut werden. Dies bezieht sich nicht nur auf das o.g. CALMS, sondern auch auf die agilen Software-Entwicklungsprozesse – diese müssen für eine CD-Pipeline wirklich agile werden.
  • Das technische Know-How für den Aufbau der CD-Pipeline und dessen Betrieb muss etabliert werden.
  • Die CD-Pipeline muss erstellt werden – dazu müssen fast immer bestehende Applikationen und Systeme auf die CD-Pipeline portiert werden

Infrastruktur und CD-Pipeline muss auf der Basis der zu entwickelnden Software-Produkte designend werden. Dies kann in Form von zwei Projektphasen geschehen in denen zunächst die Kern-CD-Pipeline gebaut und diese dann in der zweiten Projektphase dann die zu erstellende Software angepasst wird. Danach wird die Produktion weitere Releases innerhalb der Line Organisation mittels der CD-Pipeline durchgeführt.

An der agilen Vorgangsweise führt hier kein Weg vorbei, und stellt eine zusätzliche Herausforderung dar.

Continuous Delivery Phases

Es ergeben sich drei ineinander übergehende Phasen, wie in der Abbildung oben schematisch dargelegt:

Building the core CD-Pipeline:

Es muss zunächst eine CD-Pipeline in der Grundstruktur aufgebaut werden. Der Kern der CD-Pipeline wird in der ersten Projektphase erstellt, wobei sich kleinere Nacharbeiten noch in dioe Projektphase 2 hineinziehen

Adapt CD-Pipeline to software product:

Bereits im letzten Drittel beginnen die DevOps mit den Anpassungen der Kern-CD-Pipeline. Die Hauptarbeit geschieht aber in der zweiten Projektphase. Letzte arbeiten ziehen sich dann noch in den Regelbetrieb hin.

Functional Software Development:

Das Hauptaugenmerk der funktionalen Software-Entwicklung liegt in der Linienorganisation. Allerdings wird bereits in der Project Phase 1 erste mit Funktionalität implementiert und mit dem Aufbau der CD-Pipeline synchronisiert werden. Sollten sich schon hier die Entwicklungsstränge auseinanderentwickeln, ist der Projekterfolg bereits jetzt hochgradig gefährdet.

Es liegt auf der Hand, dass es z.B. eine völlig verfehlte Strategie wäre, die DevOps Engineers in einem eigenen Team zusammenzufassen, die den Entwicklern die CD-Pipeline „hinstellt.“ Daran sind schon viele DevOps-Einführungen gescheitert.

Weiterhin zeigt die obige Abbildung auch die eingesetzten Ressourcen:

Functional Developers:

Die funktionalen Programmierer sind bereits in Phase 1 und Phase 2 dabei, wenn z.B. bereits funktionale Prototypen erstellt werden.  Zu diesem Zeitpunkt  muss sichergestellt werden, dass sich die funktionale Software nicht zu sehr von den Erfordernissen der CD-Pipeine entfernt.

DevOps Engineers:

Die Arbeit der DevOps Engineers hat den größten Umfang in den beiden ersten Projektphasen bei der Erstellung der der Kern-CD-Pipeline und deren Anpassung an das zu entwickelnde Software-Produkt. Danach, in der Produktionsphase der Linienorganisation nehmen DevOps Änderungen und Wartungsarbeiten sowie den Third-Level Support.

⇒ Es muss auf jeden Fall sichergestellt werden, dass Entwickler und DevOps eng verzahnt arbeiten. Ab Mitte der Projektphase 2 nehmen die Auslastung und/oder die Menge der eingesetzten Ressourcen zu, dies geschieht aber nicht um Größenordnungen. Der Autor hat in diesem Zusammenhang gute Erfahrungen mit Kanban gemacht.

Operations:

Vom Anfang an ist Operations mit von der Partie. Zunächst geht um Unterstützung beim Aufbau einer CD-Pipeline auf Infrastruktur-Level. Danach geht es um deren Betrieb bei der Erstellung der eigentlichen funktionalen Softaware.

⇒ Noch einmal: Developers, Operations und DevOps Engineers arbeiten nicht getrennt voneinander nebeneinander her, wie es die obere Abbildung vielleicht zu suggerieren scheint. Das Projekt wird fehlschlagen, wenn die Anstrengungen  während der Projektphasen nicht synchronisiert sind. Ein häufig gemachter Fehler ist, dass DevOps Engineers als Silo auftreten, eine CD-Pipeline erstellen und diese dann den Entwicklern und Administratoren „vorsetzen“

So ein Phasenplan muss aufgestellt werden, um die Erwartungshaltung des Management steuern zu können. Es geht bei der Erstellung einer CD-Pipeline für komplexe Systeme um sehr große Summen. Dem Management muss klargemacht werden, dass die Releases nicht von Anfang an mit derselben Geschwindigkeit in Produktion gehen, wie sie bei einer rein agilen Herangehensweise erstellt würden – ohne freilich in Produktion zu gehen.

Somit ist es nicht nur wichtig dass DevOps Engineers eng verzahnt mit Entwicklern und Administratoren arbeiten. Vielmehr muss auch das Business oder die Kunden mit eingebunden werden, die über den Inhalt eines jeden Releases als Ergebnis informiert werden.  Das Ganze muss u.a. durch eine entsprechend agile Release-Planung und Projektplanung flankiert werden.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

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