Suche
Interview mit Eduards Sizovs

Continuous-Delivery-Horrorstorys… und wie man sie verhindert

Coman Hamilton

Eduards Sizovs

Die Einführung von Continuous Delivery bedeutet, liebgewonnene Gewohnheiten aufzugeben. Dass das gar nicht so einfach ist, zeigt Eduards Sizovs (Sizovs.net) in seiner DevOpsCon-Session „Eight Things that make Continuous Delivery go Nuts.“ Im JAXenter-Interview gibt er Continuous-Delivery-Horrorstorys zum besten und erklärt, welche tiefgreifenden Veränderungen Continuous Delivery auf Unternehmensebene mit sich bringt.

JAXenter: In deiner Session auf der DevOpsCon konzentrierst du dich auf die Probleme, die Teams mit Continuous Delivery haben. Was sind deiner Erfahrung nach die größten Hürden, auf die Teams treffen, wenn Sie sich in Richtung Continuous Delivery bewegen?

Eduards Sizovs: Da jede Organisation einzigartig ist, wiederholen sich Hürden so gut wie nie, und das macht die Herausforderung daran aus. Trotz der Heterogenität der Schwierigkeiten sticht aber trotzdem ein typisches Problem hervor: der Mangel an organisatorischer Ausrichtung. Unternehmen versuchen häufig, Continuous Delivery von oben herab einzuführen, obwohl das Team gar nicht bereit ist, diese Idee aufzunehmen. Das Gegenteil kann allerdings auch zutreffen – das Team möchte Continuous Delivery implementieren, bekommt aber keine Unterstützung vom Management oder anderen Teams, vor allem von den traditionell eher veränderungsresistenten Unternehmensbereichen wie der Sicherheitsabteilung oder den Operations. Normalerweise erfordert Continuous Delivery signifikante architektonische und organisatorische Veränderungen und kann zu einer teuren und zeitraubenden Aktion werden. Die Unterstützung von zahlenden Kunden zu bekommen, kann schwierig werden und erfordert Fakten, Zahlen und ROI-Analysen. Oft endet die Aktion hier, und die Beteiligten geben auf.

Ich schlage vor, Continuous Delivery wie eine lange Reise zu behandeln, nicht wie einen kurzen und teuren Marathonlauf. In der Praxis heißt das, dass man etwa 10 bis 20 Prozent seiner Zeit mit der Implementierung von Continuous Delivery in kleinen Schritten verbringen, statt „die Welt anzuhalten“ und ins kalte Wasser zu springen. Erstens wird es so viel einfacher sein, die Zustimmung der restlichen Organisation zu bekommen; zweitens – Continuous Delivery ist nie fertig oder abgeschlossen, und 10-20% der Zeit darein zu investieren ist genug, um kontinuierlich besser darin zu werden.

JAXenter: Und was ist deine schlimmste Continuous-Delivery-Horrorgeschichte?

Eduards Sizovs: Ich habe beobachtet, wie ein erfahrenes Team an Continuous Delivery gearbeitet und ihre technische Ausstattung über mehrere Monate hinweg modernisiert hat – sie haben Container eingeführt, Docker-Container in Docker-Container und diese wieder in Docker-Container gepackt etc. Überraschenderweise waren die Beteiligten dann aber nicht in der Lage, zu beherrschen, was sie gebaut haben; sie haben die Kontrolle über das Gesamtsystem verloren und die Auslieferung wurde langsamer als jemals zuvor. Das Team war dazu gezwungen, den Prozess rückgängig zu machen und brauchte dafür ein paar weitere Monate. Mit den heutigen IT-Kosten – das war ein wirklicher Albtraum.

Ich werde während meiner Präsentation auf der DevOpsCon noch mehr Horrorgeschichten erzählen. Ja, und ich werde über Leute reden, die gefeuert wurden, weil sie gescheitert sind.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

JAXenter: Bezogen auf die alltägliche Arbeit eines Entwicklers: Was ändert sich für Programmierer, die in einer Continuous-Delivery-Umgebung arbeiten im Vergleich zu Projekten, die langsamere Release-Cycles haben?

Eduards Sizovs:  Es gibt einen Beschleunigungseffekt in der Softwareentwicklung (beschrieben von Kent Beck). Während der Umstellung auf kürzere Auslieferungs-Abstände muss ein Team bestehende Gewohnheiten und Routinen aufgeben und neue entwickeln und anwenden. Um schneller zu werden, ist es zum Beispiel notwendig, ein Finetuning der Prozesse vorzunehmen und sinnlose Aktivitäten zu eliminieren. Übergaben zwischen Mitarbeitern und Nacharbeiten sind klassische Kandidaten für Eliminationen. Das mag sich einfach anhören, ist aber gar nicht so leicht. Für Entwickler könnte das zum Beispiel heißen, Methoden anzuwenden, die sie nie zuvor benutzt haben, wie TDD, Pair Programming (oder sogar die Zusammenarbeit mit QA Professionals!) oder die Verwendung von Feature Branching auf Code-Level. Insgesamt übt Continuous Delivery Druck auf unsere Fähigkeiten aus, und das ist grundsätzlich eine gute Sache, da es professionelles Wachstum ermöglicht und die Produktqualität insgesamt erhöht.

JAXenter: Ist Continuous Delivery immer die richtige Wahl? Gibt es Fälle, in denen es Sinn macht, nicht den Weg der Continuous Delivery zu nehmen?

Eduards Sizovs:  In einer perfekten Welt würde jeder zuverlässig und in kurzen Abständen liefern, aber alles hat seinen Preis. Continuous Delivery bedeutet, dass in die Infrastruktur investiert werden muss, in die Automatisierung, das Testen und die Architektur. Also müssen Vorteile und Kosten gegeneinander abgewägt werden.

Macht es Sinn in einen Prototyp zu investieren, der eh verworfen wird? Ich bezweifele es! Macht es Sinn, in tägliche Deployments für ein Produkt zu investieren, das stillsteht? Ich bezweifele es!

Der Prozess des „Live-gehens“ ist häufig nicht so einfach wie das Update eines Webservers. Sagen wir, du musst physische Hardware produzieren, eine ganze Abteilung weiterbilden oder eine riesige Menge an Dokumentationen in diversen Sprachen schreiben. Die erwähnten Faktoren sind nicht selten und müssen mit einbezogen werden, bevor der Release Cycle bis ins Extreme verkürzt wird.

Continuous Delivery sollte außerdem nicht als „alles oder nichts“ betrachtet werden – man kann ganz einfach einige Teile davon weglassen. Für die meisten Unternehmen ist eine Infrastruktur auf dem Level von Netflix nicht notwendig, um kontinuierlich und verlässlich auszuliefern. Man kann (und sollte) sich auf eine minimale Anzahl an Tools und Abläufen beschränken, die für deine Organisation funktionieren.

JAXenter: Auf der anderen Seite: Was sind die größten positiven Folgen, die Teams wahrscheinlich durch einen Continuous-Delivery-Ansatz erleben werden?

Eduards Sizovs: Continuous Delivery macht Veränderungen einfach und sicher. Je einfacher Veränderungen sind, desto mehr werden schnell in die Produktion gehen. Frühzeitigere Veränderungen ergeben schnelleres Feedback. Und schnelles Feedback ist ein Geschenk des Himmels, weil es dich deine Resultate deiner Arbeit schnell sehen lässt.

Was könnte schöner sein als die Erkenntnis, dass die Arbeit, die du machst, sinnvoll für deine Kunden ist? Mit Sicherheit wirst du dann auch von diesen glücklichen Kunden profitieren!

JAXenter: Vielen Dank für dieses Interview!

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: