© Liashko/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 Integ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang