Martin Heller diskutiert Aufwand und Nutzen von CD und CI

Continuous Delivery: Technologie allein ist nicht genug

Moritz Hoffmann

(c) shutterstock.com / jane 0606

Im letzten State of Software Delivery Report gaben über die Hälfte aller befragten Unternehmen an, Continuous Delivery (CD) in die tägliche Arbeit übernehmen zu wollen. Diese Zahlen nahm der Berater, Manager und Autor Martin Heller zum Anlass, um das Versprechen der kontinuierlichen Software-Auslieferung kritisch unter die Lupe zu nehmen. Zweifellos könne CD große Geschäftserfolge bringen, die Frage müsse aber zunächst lauten: Zu welchem Preis?

Bessere Software liefern und zwar schneller als bisher, so lautet der Slogan einer beliebten Continuous-Delivery-Plattform. Das klingt doch wunderbar, was aber ist die konkrete Idee hinter dem DevOps-Tool und wo liegt der Unterschied zu Continuous Integration (CI)?

Martin Heller folgt eine bekannten Definition der Consulting-Firma Thoughtworks, der zufolge es sich bei CD um eine Art natürlicher Verlängerung von CI handelt. Geht es dort um die täglich mehrfach erfolgende Integration von Code in ein geteiltes Repository, der dann automatisiert getestet wird, um mögliche Probleme frühzeitig zu erkennen und zu beheben, richtet sich CD auf die garantierte Möglichkeit, Software mit jeder Veränderung auch sofort als Produkt bzw. Teilprodukt auf den Markt bringen zu können.

Nichts ist einfach „einfach“

Was laut Heller in der allgemeinen Begeisterung für die so erzielte Verkürzung der Time-to-Market oft untergeht, sei eine realistische Einschätzung des Aufwandes, der nötig ist, um CD/CI-Konzepte auch wirklich umzusetzen. Dazu gehöre weit mehr als Software und ein wenig Setup-Arbeit. Oftmals sei ein vollständiger Wandel der Entwickler-Kultur nötig, eine Umgestaltung des Workflows, die Automatisierung der bestehenden Tests und die Installation einer gewaltigen Infrastruktur, wenn nicht sogar ein kompletter Umzug in die Cloud die beste Lösung ist. Hellers Einschätzung zu den notwendigen Maßnahmen:

None of that is impossible, but none of that is easy. The technical parts are easier than the organizational and cultural parts of this shift.

So könne es schon schwierig sein, in langwierigen internen Diskussionen die Verfügbarkeit der Repositories auf GitHub durchzusetzen. Weitaus schwieriger aber sei es noch, dafür Sorge zu tragen, dass die verantwortlichen Entwickler nicht nur ihre täglichen Check-Ins absolvieren, sondern auch vor jedem Coding-Vorgang von GitHub pullen, jederzeit auftretende Konflikte mergen und Tests schreiben, die unkompliziert automatisiert werden können. Zur Verdeutlichung greift Heller auf ein technisch handfestes Beispiel zurück:

It’s easy to use Jenkins, for example, to trigger builds on check-ins and send out reports to the appropriate developers; it’s harder to make the developers pay attention to the reports in a timely fashion and shelve their new development to fix their older mistakes.

Tod durch Entwickler – Continuous Integration bereits gescheitert?

Zudem sei nicht ausgemacht, dass es die Veröffentlichung jeder neuen Produktversion per Knopfdruck in jedem Fall eine gute Sache sei. Möglicherweise würden so auch Features freigegeben, die wegen einer mangelhaften Dependency noch nicht für die Endnutzer geeignet sind. Es ist schön, so Heller, Features schnell integrieren und testen zu können, aber man muss sich schon etwas ausdenken, um sie dann noch vor der Öffentlichkeit verbergen zu können.

Ein weiteres Problem sei die Bereitschaft der Entwickler, bei einem entdeckten fehlerhaften Build, sofort die aktuellen Arbeiten zugunsten der Fehlerbehebung stehen und liegen zu lassen, wie im Konzept der Continuous Integration eigentlich vorgesehen. Nach Hellers Erfahrung ist das in der Praxis einfach nicht der Fall. Ein Anderer, darauf weist Heller hin, hat nicht zuletzt deshalb CI bereits für tot erklärt.

Fazit

Hellers Einwände laufen zusammenfassend auf den Umstand hinaus, dass die technischen Innovationen für einen sinnvollen und nutzbringenden Einsatz von Continuous Delivery nur die halbe Miete sind. Es komme darauf an, sie richtig anzuwenden. Der Aufwand, um eine entsprechende Entwickler-Kultur im Rahmen der neuen DevOps-Philosophie zu etablieren, kann je nach vorheriger Unternehmensstruktur immens sein. Ob es sich ein solcher Schritt wirklich lohnt, bleibt wohl im Einzelfall, vor allem aber im Vorfeld zu prüfen.

Aufmacherbild: Baton/relay/race/a people pass the baton to the other via Shutterstock.com
Urheberrecht: Jane0606

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: