© Enkel/Shutterstock.com
Warum Continuous Delivery manchmal scheitert

Sieben Mal daneben …


Kontinuierliches Liefern (Continuous Delivery) und Infrastructure as Code sind Mainstream, oder? Zumindest behaupten viele, es zu praktizieren. Wer es nicht macht, ist draußen (neudeutsch: out) – oder zumindest ganz weit drin im Zimmer. Konsequent zu Ende betrachtet müssten wir also eine enorme Verbesserung der Liefergeschwindigkeit in unserer IT-Welt sehen – und zwar nicht nur bei kleinen Unternehmen und Projekten.

Doch verlässt man das gewohnte Zuhause der Entwickler, Administratoren und IT-Abteilungen und zwingt sich in die Perspektive eines Geschäftsbereichs, der von der Zulieferung aus der IT abhängig ist, so stellt man ernüchtert fest, dass die Geschwindigkeitsverbesserung durch die modernen Technologien selten von außen wahrnehmbar ist. Woran liegt das?

Es gibt viele Gründe, weshalb Anwender und Kunden die Geschwindigkeitssteigerungen von DevOps und insbesondere Continuous Delivery von außen nicht wahrnehmen. Oft liegen große Schwierigkeiten in der Kollaboration und Kommunikation im Team [1], doch Werkzeuge und Technologien stehen selten im Verdacht. Wahrscheinlich boomen deshalb auch alle möglichen DevOps-Tools. Doch die Erfahrung zeigt, dass auch der Aufbau und Einsatz von Werkzeugen zum kontinuierlichen Liefern allein nicht zwingend zum Erfolg führt. Es gilt wieder einmal die altgediente Weisheit von Grady Booch: „A fool with a tool is still a fool“ („Ein Dummkopf mit einem Werkzeug bleibt ein Dummkopf“).

Die kontinuierliche Liefer-Pipeline (Continuous Delivery)

Um die sieben Fallen zu verstehen, braucht es zunächst einmal ein gemeinsames Verständnis von einer modernen, kontinuierlichen Liefer-Pipeline (Abb. 1). Ziel einer solchen automatisierten Lieferkette ist es, möglichst häufig Änderungen in Produktion zu bringen, um danach möglichst schnell Rückmeldung von realen Nutzern und Kunden zu erhalten. Am Ende entstehen Systeme schneller und zusätzlich maßgeschneidert auf die tatsächlichen Bedürfnisse derjenigen, die Hilfe und Erleichterung ihres Privat- oder Berufslebens erhalten sollen.

rederlechner_devopsfails_1.tif_fmt1.jpgAbb. 1: Idealisierte DevOps-Liefer-Pipeline

Typischerweise arbeitet ein cross-funktionales Team im agilen Modus in der Entwicklungsstufe an Features, die es im Rahmen eines Sprints entwickelt, durch Tests absichert und schließlich automatisiert ausrollt. Im Unterschied zur klassischen Vorgehensweise sollen die Entwicklungsarbeit und überhaupt alle manuellen Tätigkeiten hier gebündelt sein („Linksverschiebung“). Die Stufe Entwicklerqualität der Continuous Integration dient dazu, sicherzustellen, dass die für das Feature zuständige Gruppe eine lauffähige Erweiterung mit einem Mindestqualitätsniveau abliefert. Neben Codescannern dokumentieren Unit-Tests schwierige Durchlaufpfade durch den Code und prüfen das korrekte Verhalten im Regen, d. h., bei nicht ganz so positiven Durchläufen (rainy day scenarios). Danach baut die Build-Stufe nicht nur Bibliotheken und andere Laufzeitfragmente. Beim kontinuierlichen Liefern werden zusätzlich Lieferpakete (genannt Images) gebaut, die die Pipeline später unverändert in den verschiedenen Regressionen bis zur Produktion installiert.

Vor der Produktionsentscheidung arbeitet das Team so lange, bis es die umgesetzte Funktion mit gutem Gewissen einem Nutzer an die Hand geben kann. Außerdem muss die Continuous Integration „grün“ sein, d. h. der Durchlauf der entsprechenden Stufen verläuft erfolgreich. Ein Product Owner entscheidet dann zusammen mit dem Team, ob das Feature in Produktion geht. Das ist gleichzeitig die Entscheidung, dass die kontinuierliche Liefer-Pipeline startet und ungebremst bis zur Produktion durchläuft.

Da sich mittlerweile die Ausgangssituation geändert haben kann, durchläuft Continuous Delivery zunächst noch einmal die Integrationsstufen. Alle weiteren Stufen danach dienen dazu, mögliche übersehene Seiteneffekte auf bereits ausgerollte Funktionen zu vermeiden. Die Businessregression sucht nach fachlichen Auswirkungen und lässt dazu möglichst alle bisher durchgeführten Fachtests automatisiert ablaufen. Die nichtfunktionalen Regressionen dienen dazu, technische Einflüsse wie z. B. reduzierte Performanz abhängiger Features zu entdecken. Außerdem helfen sie, Bereiche abzusichern, die möglicherweise gerade nicht im Fokus des Teams gestanden haben (wie z. B. die Systemsicherheit). Bei jedem der Testbereiche installiert die Pipeline frische, produktionsnahe Umgebungen und übt damit den Rollout für die Produktion.

Fachfreigaben sind in diesem Szenario nicht zwingend erforderlich. Denn eigentlich entscheiden die Nutzer eines Systems darüber, ob ein Feature tatsächlich funktioniert oder nicht. Kontinuierliches Liefern endet erfolgreich mit einer lauffähigen Installation in Produktion und der erfolgreichen ersten Nutzung der neuen Funktion durch einen Anwender.

Die gesamte Konstruktion klingt vernünftig und ist anscheinend mittlerweile häufig bei coolen Firmen im Einsatz. Was also soll da schon schiefgehen?

Falle 1: Eine unpassende Branching-Strategie

Versionkontrollierte Entwicklung ist mittlerweile in allen professionellen Development-Methoden fester Bestandteil. Doch trotz flexibler Werkzeuge wie Git kann der unbedachte Einsatz von Branches (Entwicklungszweigen) in einem Albtraum münden.

Zweige sind beliebt, da sie es ermöglichen, an einem beliebigen Punkt von der Hauptentwicklung abzuweichen und mit wenigen Personen erst einmal ungestört vom Rest eine Erweiterung zum Laufen zu bringen. Sie ermöglichen ungestörtes Arbeiten. Leider haben Zweige die unangenehme Eigenschaft, schnell zu altern. Je länger ein Team unabhängig vom Hauptzweig arbeitet, desto schwieriger wird es, die beiden Entwicklungsstr...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang