Suche
Expertencheck Teil 1

Continuous Delivery im Expertencheck: Von Problemen beim Start und dem Scheitern

Melanie Feldmann

© Shutterstock / KreativKolors

Continuous Delivery verspricht schnellere Release-Zyklen und eine bessere Softwarequalität. Oft sieht das Ergebnis aber ganz anders aus. Sechs Continuous-Delivery-Experten geben Tipps wie der Start gelingt und welche Hindernisse auf jeden Fall aus dem Weg geräumt werden müssen, damit CD nicht scheitert.

Lesen Sie den kompletten Schwerpunkt zum Thema Continuous Delivery im Java Magazin

Was hättest du gerne gewusst, als du mit Continuous Delivery (CD) angefangen hast?

Robin Bühler: Für diese Frage gibt es sicherlich eine Vielzahl an Antwortmöglichkeiten, aber ich würde sagen, dass wir initial das Potenzial von vollautomatischen Tests nur ansatzweise erkannt haben. Zu den vollautomatischen Tests zählen wir allerdings nicht nur Unit- und Integrationstests, sondern vor allem auch Akzeptanz- und Infrastrukturtests.

Bernd Greifeneder: Dass Continuous Delivery oder Continuous Deployment eigentlich ein ungenügender Begriff ist. Es sollte CDF, Continuous Delivery und Feedback heißen – und Continuous Deployment und Feedback (CDF) gleichermaßen. Wir hätten uns viele Kollaborationsprobleme durch umgehendes Feedback sparen können. Heute wissen wir, dass Feedback das wichtigste Mittel ist, um Kultur und Teamwork in die richtige Richtung zu formen. Die Teams müssen auch bei großen Projekten innerhalb von fünf bis zehn Minuten wissen, ob sie die CD-Pipeline gebrochen haben.

Die Continuous-Delivery-Experten

Dr. Robin Bühler, IT Architect bei Allianz Managed Operations & Services

Bernd Greifeneder, CTO von Dynatrace

Christian Kühn, Systementwickler synyx

Mathias Meyer, CEO Travis CI

Oliver Wehrens, Chief Architect bei Deutsche Post E-Post Development

Eberhard Wolff, Fellow bei innoq

Christian Kühn: Mein persönlicher Start in CD war die Zusammenführung von Code und Build-Tool, namentlich git und Jenkins, zu einer automatischen Verkettung von Code-Neuerungen zu neuen Builds. Mir fehlte aber die Kenntnis über weitere Tools, die ich nicht mehr missen möchte, vor allem zur Sicherstellung von Codequalität wie . SonarQube, Job-Automatisierung, z. B. mit Rundeck, und natürlich Chatops, um Kommunikation und Teamwork zu fördern.

Mathias Meyer: Die Anfänge mit CD sind meistens die schwierigsten. Je nach Alter der Firma und Erfahrungsgrad des Teams ist es ein langwieriger und steiniger Prozess, die Änderungen durchzubringen ohne jemanden auf dem Weg links liegen zu lassen. Die Änderung lässt sich nicht erzwingen, sondern muss, gerade in älteren Firmen  und Teams – basierend auf Erfahrung und Existenz –, graduell angegangen werden. Kleine Schritte helfen hier am besten, z. B. mit einem kleinen Teil der Produkt oder Projektlinie anzufangen und nach und nach die Vorteile und Möglichkeiten zu zeigen. Partizipation und gute Beispiele sind immer noch die besten Motivatoren.

Oliver Wehrens: Continuous Delivery ist eine Organisations- und Mindset-Veränderung. Bestehende Prozesse und Arbeitsaufteilungen werden teilweise radikal umgebaut. Dies hatten wir am Anfang etwas unterschätzt.

Eberhard Wolff: Der Fokus bei Continuous Delivery liegt häufig zu sehr auf Infrastrukturautomatisierung.  Der Schlüssel dazu, Software öfter und schneller auszuliefern, ist nicht das Deployment selbst, sondern die oft sehr lange laufenden Tests. Trotz erfolgreicher Tests bestehen vielfach Zweifel an der Fehlerfreiheit der Software. Darin liegt ein großes Optimierungspotenzial. Außerdem muss bei Continous Delivery auch die Architektur hinterfragt werden. Wenn die Software nicht einfacher deploybar gemacht wird, kann der Aufwand für die Einführung von Continuous Delivery schlicht viel zu hoch werden.

Woran scheitert CD?

Robin Bühler: In meinen Augen scheitert Continuous Delivery primär an organisatorischen und kulturellen Problemen in Organisationen, die bereits eine gewachsene IT-Landschaft samt zugehöriger gewachsener Betriebs- und Release-Kultur haben. Weiterhin sehe ich das Thema manuelle Trigger für Aufgaben, die eigentlich im Rahmen eines Self-Service-Prozesses laufen sollten, als weitere Herausforderung, die häufig zu einem Scheitern von CD führt.

Bernd Greifeneder: Es scheitert am Glauben an die Technik. Man denkt, dass es bei CD hauptsächlich um Automatisierungstechnologie geht. Stimmt, auch wenn man nur die Technik betrachtet. Dass es bei CD(F) nur um 20 Prozent Technik aber um 80 Prozent Kultur, Organisation und Prozess geht, erwartet man anfangs nicht. Auch nicht dass es dazu das Business braucht, um die notwendigen Organisationsänderungen durchzuführen.

Christian Kühn: Meiner Ansicht nach kann CD maximal am mangelnden Willen zu Neuerungen und natürlich an schlechter Umsetzung scheitern. Man sollte unbedingt alle Stellen, die am Softwareentwicklungs- und Betriebsprozess beteiligt sind, mit ins Boot holen und sie mit ihrem Wissen und ihrer Erfahrung Einfluss nehmen lassen. Zurzeit häufen sich leider immer wieder Schlagzeilen über ungesicherte Daten im Internet, die z. B. aus schlecht administrierten Datenbanken geleakt werden, weil viele Firmen nicht verstehen, dass auch die besten Prozesse und Toolchains nichts taugen, wenn bei deren Aufbau das Know-how eines guten Sysadmins fehlt.

Mathias Meyer: Die einfache Antwort ist, dass die Einführung von CD oft aus kulturellen Gründen scheitert. Das ist aber zu einfach gestrickt, zumindest meiner Erfahrung nach. CD scheitert am häufigsten am fehlenden Support und Verständnis von ganz oben. Wenn die Führungsetage nicht versteht, was CD sowohl für die Kultur als auch den Kunden bedeutet und welche Änderungen notwendig sind, um interne Prozesse umzustellen, helfen die besten Initiativen von unten nichts. CD bedeutet Vertrauens ins und Freiheit fürs Team. Es bedeutet aber auch, dass die Initiativen hierzu von oben gefördert und unterstützt werden müssen.

Meiner Erfahrung nach führt mangelndes Verständnis der Vorteile aber auch der Risiken und notwendigen Änderungen und Zeitkontingente zur frühzeitigen Aufgabe. Hier hilft nur ein Management, das sich der Vorteile bewusst ist und die Umsetzung aktiv steuert. CD scheitert selten an technischen Herausforderungen, diese sind meistens lösbar. Nein, es scheitert weil Ungeduld, Mangel an Zeit und mangelnde Wertschätzung für den Kunden dazu führen, dass die Initiativen abgebrochen werden. In Zukunft wird sich das allerdings kaum noch eine Firma leisten können. Der Druck durch Kunden und Konkurrenz wird nur noch größer werden.

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Oliver Wehrens: CD scheitert an Veränderungsunwilligkeit in der Organisation. Die Aufgaben müssen neu geschnitten werden. Wenn eine Software fünfmal am Tag geliefert werden soll, muss eine Testabteilung anders arbeiten, um nicht zum Flaschenhals zu werden. CD scheitert auch an fehlendem Invest in Softwarequalität und Automatisierung. Wurde früher in der Testabteilung getestet und vom Betrieb deployt, muss mit CD dieses schon viel früher bei den Entwicklern automatisiert passieren. Fehlt hier der Invest scheitert auch CD.

Eberhard Wolff:  Für Continuous Delivery müssen alle zusammenarbeiten – Kunden, Entwickler und Betrieb. Betrieb und Entwicklung setzen gemeinsam die Continuous-Delivery-Pipeline um. Kunden und Entwickler implementieren automatische Tests, damit aufwendige manuelle Tests entfallen. Zu oft sind Teams an Kollaboration nicht gewöhnt. Ein weiteres Problem sind unklare Ziele. Continuous Delivery kann Time-to-Market verbessern. Dann muss die Geschäftsseite daraus auch einen Vorteil ziehen können. Sonst können andere Ziele wie höhere Zuverlässigkeit durch Automatisierung von Tests und Deployment sinnvoll sein.

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.