Continuous Lifecycle 2015 im Zeichen von Docker und Continuous Delivery
Zum dritten Mal bereits fand Mitte November die Continuous Lifecycle statt. Das Interesse an den Leitthemen der Konferenz ist weiterhin hoch.
- Falk Sippach
Zum dritten Mal bereits fand Mitte November die Continuous Lifecycle statt. Das Interesse an den Leitthemen der Konferenz – DevOps, Continuous Delivery und Containerisierung – ist weiterhin hoch, und so wurden die Besucherzahlen vom Vorjahr erneut übertroffen.
Gekommen waren in den Mannheimer Rosengarten mehr als 400 Wissensdurstige, die an zwei Tagen aus knapp 40 Vorträgen in drei parallelen Tracks auswählen konnten. An zusätzlichen Tagen gab es die Möglichkeit, ein Spezialthema in zumeist ausverkauften Workshops zu vertiefen.
Das Programm war wieder vielfältig, es stachen aber einige Themen deutlich hervor. So wurde gefühlt bei jedem zweiten Vortrag das Thema Docker angesprochen. Man merkt, dass diese Art der Betriebssystemvirtualisierung in kürzester Zeit im Mainstream angekommen ist. Und so war das Interesse bei den Teilnehmern hoch, auch wenn es bisher nur wenige wirklich produktiv einsetzen.
Das Publikum schien überhaupt stärker am Einsatz von und Erfahrungsberichten zu Werkzeugen interessiert zu sein. Man hatte den Eindruck, dass in diesem Jahr mehr Zuhörer aus dem Lager der Operations da waren. Sie hätten sich teilweise mehr Tiefe gewünscht, ihnen kam der Betriebsaspekt bei den zumeist aus Entwicklersicht vorgetragenen Vortragsthemen oft zu kurz. Das ließ sich an den regen Diskussionen und Fragerunden am Ende diverser Vorträge ablesen.
Vom Wasserfall zu Continuous Delivery
Als Keynote-Speaker konnten Dave Farley (Co-Autor des bekannten Buchs zu Continuous Delivery) und Jutta Eckstein (Urgestein im agilen Umfeld) gewonnen werden. Farley hatte die Ehre, die Konferenz zu eröffnen, und stimmte die Teilnehmer mit einem unterhaltsamen, aber mit vielen Fakten gespickten Vortrag zu den Grundlagen von Continuous Delivery ein. Eckstein ging hingegen am zweiten Tag stärker auf die weichen Faktoren bei der Einführung von Continuous Delivery ein und hatte damit das Thema der letztjährigen Konferenz, den Cultural Change, aufgegriffen.
Dass bei den klassischen Softwareentwicklungsansätzen die Rate der gescheiterten Projekte deutlich höher sei, belegte Farley in seiner Keynote anhand diverser Statistiken. Diese zeigen, dass Projekte nach klassischen Ansätzen zu häufig scheitern oder sich zumindest nicht in der gewünschten Zeit beziehungsweise dem angestrebten Budget umsetzen lassen. Bei Projekten mit großem Volumen könne ein Scheitern zudem den Bankrott ganzer Firmen zur Folge haben.
Es folgte ein kurzer Abriss durch die Geschichte vom Wasserfall hin zu agilen Praktiken. Dabei machte Farley darauf aufmerksam, dass das Wasserfall-Modell missverstanden und nicht korrekt interpretiert worden sei. Man hatte bereits in den 70er-Jahren des 20. Jahrhunderts erkannt, dass Feedbackschleifen nötig seien, ein Projekt zum Erfolg zu bringen. In den Köpfen festgesetzt hatte sich aber das einfache Modell mit der sequenziellen Abfolge der Phasen, wodurch das ganze System unflexibel und sehr aufwendig wurde.
Durch agile Methoden sind IT-Abteilungen nun einige Jahrzehnte später aber doch noch bei inkrementellen und iterativen Vorgehensweisen angekommen. Sie versprechen frühes Feedback und steigern somit die Qualität von Softwareprojekten deutlich. Studien haben gezeigt, dass unter den agilen Methoden die Ideen des Lean Thinking zu den Ergebnissen mit der höchsten Erfolgsquote und den wenigsten Totalausfällen führen.
Lean Thinking an der Spitze
Für Farley ist Lean Thinking mit schnellen und häufigen Auslieferungen guter Qualität und dem Vermeiden unnötiger Arbeitsschritte verbunden. Das Team bekommt mehr Macht, das Lernen voneinander steht im Vordergrund, und zudem werden Entscheidungen möglichst spät getroffen. Damit vermeidet man nachträgliche teure Änderungen und verbaut sich nicht frühzeitig den Weg. Der Projektablauf wird dabei als Ganzes optimiert.
Um diese Ziele zu erreichen, benötigt man kurze Projektzykluszeiten. Gemeint ist dabei der zeitliche Umfang von der Idee für ein Feature bis zur Inbetriebnahme einer Software. Das ist für Farley eine der wichtigsten Metriken moderner Softwareprojekte. Klassische Vorgehensweisen benötigen Wochen oder sogar Monate, um ein Feature in Produktion zu bringen. Das sei nicht mehr zeitgemäß und bedeute für viele Firmen extreme Wettbewerbsnachteile (Stichwort: Time to Market). Continuous Delivery mit der dafür notwendigen Automatisierung der Infrastruktur, des Test-, Build- und Deploymentprozesses stellt einen möglichen Ausweg aus dem Dilemma dar. In einem Beispiel aus der Finanzwelt sprach er gar von Cycle Times unter einer Stunde. Für die sonst konservative Finanzbranche liegen die Vorteile auf der Hand, und die Aussage "Zeit ist Geld" bekommt in diesem Zusammenhang eine ganz neue Bedeutung. Continuous Delivery kostet also nicht nur Geld; richtig eingesetzt steigert es vielmehr die Umsätze.
In Farleys Keynote durfte auch das agile Manifest nicht fehlen. Das erste Prinzip besagt: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Diese Denkweise ist die konsequente Fortsetzung von Continuous Integration. Jeder Commit erzeugt einen Release-Kandidaten, wobei ein Feature erst fertiggestellt ist, wenn es in die Produktion gebracht wurde. Durch konsequente Versionskontrolle und einen möglichst hohen Grad an Automatisierung führte Continuous Delivery zu wiederholbaren und zuverlässigen Software-Release-Prozessen. Natürlich müsse man dauerhaft bestrebt sein, diese Abläufe zu verbessern. Trotz anfänglicher Schmerzen sollte man die Prozesse fortwährend vorantreiben, um die Qualen letztlich zu minimieren. Die Schnell-Schnell-Mentalität sei keine Option, das Abliefern von Qualität das Ziel. Fertig sei ein Projekt erst, wenn es auch veröffentlicht ist. Diese Prinzipien funktionierten nur, wenn alle an einem Strang ziehen. Jedes Projektmitglied sei also für den Releaseprozess mitverantwortlich.
Für Kritiker, die Continuous Delivery nur für kleine Projekte als umsetzbar erachten, hatte Farley beeindruckende Zahlen von großen Playern wie Google oder Amazon parat. Außerdem brachte er wieder die häufig zitierte Fallstudie des HP-Laserjet-Firmware-Teams, das 2008 nahezu handlungsunfähig war, aber mit der Einführung von Continuous-Delivery-Praktiken das Projekt reorganisieren konnte, um wieder deutlich mehr Zeit für die Umsetzung von Innovationen zu bekommen.
Am Abend des ersten Tages debattierten Experten dann noch, ob man letztlich immer ein Gesamtpaket aus Continuous Delivery, DevOps Microservices und Docker nutzen wird, da eines zwangsläufig zu den anderen führe. Danach konnte man den Abend beim Get-together mit Fingerfood und in Begleitung einer Live-Band bei anregenden Diskussionen mit den anderen Teilnehmern ausklingen lassen.
Fazit
Aus den Gesprächen spürte man im Gegensatz zum letzten Jahr aber diesmal keinen deutlichen Ruck mehr hin zu mehr Continuous Delivery. Alle finden es gut, einige probieren es auch aus, aber die wenigsten setzen es tatsächlich in der Praxis um. Vielmehr sehen viele Releases im 4-Wochen-Takt als ausreichend an. Erst wenn es schneller gehen soll, muss man den großen Sprung, den Cultural Change wirklich wagen, und auch erst dann sind die Automatisierungen in den Prozessen notwendig. Man kann die Parallelen zu Big Data und NoSQL ziehen: Auch da sind sich alle über die Wichtigkeit dieser Ansätze einig. Wirklich konkret betreffen tut es dann aber doch die wenigsten.
Im nächsten Jahr wird es eine Fortsetzung der Continuous Lifecycle geben. Die Aufmerksamkeit für die DevOps-Themen wird konstant hoch bleiben und gegebenenfalls noch weiter steigen, da immer mehr Firmen die Vorteile erkennen beziehungsweise aufgrund betriebswirtschaftlicher Zwänge die Herausforderungen angehen müssen. Auf dem Tool-Markt wird es in den nächsten Monaten sowieso keinen Stillstand geben.
Falk Sippach
hat über 15 Jahre Erfahrung mit Java und ist bei der Mannheimer Firma OIO Orientation in Objects als Trainer, Softwareentwickler und Projektleiter tätig. Er publiziert regelmäßig in Blogs, Fachartikeln und auf Konferenzen. In seiner Wahlheimat Darmstadt organisiert er mit anderen die örtliche Java User Group.
(Ausrichter der Continuous Lifecycle sind iX, heise Developer und der dpunkt.verlag. Diese gehören zur Heise Medien Gruppe, die auch der Betreiber von heise Developer ist.) (ane)
