Auf dem Continuous Delivery Day der JAX 2016

Das A und O von Continuous Delivery: Zuverlässigkeit

Dominik Mohilo

(c) Shutterstock / Ton Snoei

Agile Softwareentwicklung ist schon Mainstream und DevOps ist auf dem Vormarsch – und irgendwo dazwischen liegt Continuous Delivery. Auf dem Continuous Delivery Day der JAX 2016 beschäftigten sich Eberhard Wolff, Bernhard Cygan, Jürgen Güntner, Amir Golan und Steffen Schulf mit den verschiedensten Aspekten des Prozesses von Build, Test und Deployment im agilen Geiste.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

– Agiles Manifest, agilemanifesto.org

Continuous Delivery (CD) umfasst weit mehr als die kontinuierliche Auslieferung von Software. Es geht, ganz nach dem agilen Manifest, auch um wertvolle, das heißt qualitativ hochwertige, für den Kunden nützliche Software. Um dies zu erreichen beinhaltet der CD-Prozess vor allem auch viele Testzyklen, in denen die Qualität der kontinuierlich ausgelieferten Softwareteile sichergestellt wird.

Ein weiterer Aspekt des CD-Prozesses, der eine zentrale Rolle spielt, ist die Automatisierung. Diese darf sich allerdings keinesfalls negativ auf die Qualität der Software auswirken. Wo die Qualität durch automatisierte Prozesse leidet, sollte ernsthaft darüber nachgedacht werden, ob die Kosten (Qualitätsverlust) den Nutzen (Geschwindigkeit) übertreffen.

Man darf den Aufwand für Continuous Delivery nicht unterschätzen

Es gibt gute Gründe für CD. In seiner Session auf der JAX 2016 hat Eberhard Wolff fünf solche Gründe aufgelistet, wobei der wichtigste – natürlich – die schnellere Auslieferung von Software ist. Neben der Schnelligkeit ist die Reproduzierbarkeit ein wichtiger Punkt in der Welt der kontinuierlichen Softwareauslieferung: Durch Automatisierung, so Wolff, sei alles im Prozess reproduzierbar. Aus Managersicht ist dies wünschenswert: Automatisierte Tests sind kostengünstiger als manuelle. Doch man sollte immer im Auge behalten, dass auch die Automatisierung nicht alles ist.

Ein weiterer Begriff, der in Verbindung mit CD immer genannt wird, ist der Begriff „Zuverlässigkeit“. Diese steht laut Eberhard Wolff dem Time-to-Market-Aspekt gegenüber und gemeinsam bilden sie die Achsen, nach denen CD ausgerichtet wird. Während in puncto Zuverlässigkeit die Tests eine zentrale Rolle spielen, ist „Time-to-Market“ ganz auf die Optimierung der Prozessgeschwindigkeit und einen konstanten „Flow“ durch die Produktionsstraße ausgelegt.

"Wenn ich kleinere Releases mache, gibt es weniger Risiko, dass ich irgendwo was kaputtmache." - Eberhard Wolff

„Wenn ich kleinere Releases mache, gibt es weniger Risiko, dass ich irgendwo was kaputtmache.“ – Eberhard Wolff

Natürlich kann es zu Problemen kommen. Viele dieser Widrigkeiten liegen an zu großen Deployment-Einheiten, sagt Wolff, sein Tipp: Microservices erstellen und für jeden Microservice eine eigene CD-Pipeline aufstellen. Der Vorteil: Die Pipelines haben jeweils weniger Abhängigkeiten, wodurch weniger Tests notwendig sind. Sie sind außerdem leichter aufzubauen und das schnellere Feedback sorgt wieder für schnellere Ausbesserung, wenn nötig.

Daher das Fazit von Eberhard Wolff: Man sollte den Aufwand für Continuous Delivery nicht unterschätzen.

Continuous Everything

Bei DevOps, Continuous Delivery und Agile denkt man automatisch an die Softwareentwicklung. Doch wie Jürgen Güntner in seiner Session verdeutlicht, nutzt es nichts, wenn nur in der Entwicklung agile Prozesse etabliert werden. Auch das Unternehmen selbst müsse agil werden. Es würde nichts bringen, so Güntner, wenn alle zwei Wochen deploybarer Code erstellt wird, die Auslieferung aber nicht stattfinde.

Agile is mainstream

DevOps is rising

Der Vergleich zwischen Marathonläufer und Sprinter nimmt in der Argumentation Güntners eine zentrale Rolle ein. Beide seien für Unternehmen wichtig, aber sie müssten sich einander annähern. Marathonläufer sollten ein wenig agiler werden, während die agilen Sprinter eine größere Institutionalisierung durchleben und besser ins Unternehmen integriert werden müssten.

"Nicht stillstehen, agiler werden!" - Jürgen Güntner

„Nicht stillstehen, agiler werden!“ – Jürgen Güntner

Wenn du nur tust, was du schon kannst, wirst du nie mehr sein, als du schon bist.

Doch mit einem verbesserten CD-Prozess sei es nicht getan. Das Ziel muss, so Güntner, Continuous Everything heissen. Das impliziert nach seinem Modell die Wartung der Produkte ebenso, wie die Weitergabe von Performancedaten und Logs an die Entwicklung. Ein weiterer Teilaspekt von Continuous Everything seien die sogenannten „Continuous Services“, also das Anbieten von Services für die Nutzer der Software, auch über den Entwicklungsprozess hinaus.

Things will break!

Etwas, mit dem man sich in der Softwareentwicklung abfinden muss, beschrieb Amir Golan: Es wird definitiv und unausweichlich passieren, dass Dinge nicht funktionieren. Das einzige, das hilft, ist es, den Radius der Zerstörung zu minimieren. Bricht man die Teile einer Software ein oder zwei Instanzen hinab, können die meisten Services funktionieren, auch wenn ein Service zusammenbricht. Diese Art der Softwareentwicklung zu etablieren bedeutet in erster Linie, seinen Denkprozess zu verändern.

Break down the Monolith – Divide and Conquer!

Continuous Delivery über die Cloud in den Prozess der Entwicklung zu integrieren bietet sich durchaus an. Natürlich kann man eine Automatisierung von Backups und das ständige Erneuern aller Instanzen auch lokal betreiben. Einfacher geht es aber eben mittlerweile in Form von Cloud Computing; auch der Zugriff ist dadurch leichter, vor allem für Unternehmen mit dezentraler Struktur.

"Automate as much as you can" - Amir Golan

„Automate as much as you can“ – Amir Golan

Erst, wenn schwere Dinge einfach werden, ist man immer bereit für den Ernstfall.

Um im Unternehmen Best Practices zu etablieren, kommt man um eines nicht herum: üben, üben, üben. Nur, wenn Ausnahmesituationen und Probleme regelmäßig geprobt werden, lernt man möglichst effektiv damit umzugehen. Zu den Best Practices, die bei der Softwareentwicklung sinnvoll sind, gehört laut Golan auch die Verwendung eines „Chaos Monkeys“, der Herz und Nieren von Services auf Stabilität prüft. Außerdem sollte man eine vertrauenswürde Test Suite für kontinuierliches Testen verwenden sowie durch „Monitoring“ und „Measuring“ die Auswirkungen jeder Änderung im Blick haben.

Continuous Delivery is all about you

Am Ende des Tages ist CD etwas Persönliches. Es kann den Unterschied zwischen Stunden und Sekunden bedeuten, wie Golan sagt, doch Weiterentwicklung kann nicht durch Stillstand erreicht werden. Daher rät er immer neue Dinge auszuprobieren und mit neuen Deployment-Strukturen zu experimentieren.

Eine davon stellte Steffen Schluff zum Abschluss des Continuous Delivery Days vor: Docker. Natürlich hatten bereits seine Vorredner Docker erwähnt, ein ausführliches Beispiel, wie Docker für CD-Pipelines genutzt werden kann, kam theoriemüden Entwicklern am späten Abend dann entgegen. Dennoch warnte Steffen Schluff vor zu viel Enthusiasmus, was Docker betrifft:

Docker ist kein Wundermittel. Es kann bei den heute angesprochenen Themen helfen, löst aber nichts von allein!

Die Killerfeatures von Docker gingen davon aus, dass Container auch für die Produktion genutzt werden. Dieses Ziel sei aber gar nicht so leicht zu erreichen, sagt Schluff. Dazu müssten vorhandene Applikationen und Anwendungen erst einmal an die Entwicklung mit Containern angepasst werden. Dennoch könne Docker, auch wenn es nicht in der Produktion genutzt werde, im Umfeld Continuous Delivery bzw. Continuous Integration (CI) spannend sein.

Achja, wer sich schon immer gefragt hat, wo der Unterschied zwischen Continuous Delivery und Continuous Integration besteht, für den hat Schluff eine einfache Erklärung: Continuous Delivery ist in fünf „Stages“ eingeteilt, nämlich Commit Stage, Akzeptanz Test Stage, Performance Test Stage, Nutzer Abnahme Stage und Produktiv Stage. Bis zur Mitte der dritten Stage sind die beiden laut Schluff identisch.

Aufmacherbild: A clock containing the life cycle of continuous delivery via Shutterstock / Urheberrecht: Ton Snoei

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: