Continuous Lifecycle 2015 im Zeichen von Docker und Continuous Delivery

Fazit

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.

Die Panelisten von links nach rechts: Eberhard Wolff (Moderation), Dustin Huptas, Jörg Müller und Peter Rossbach

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.)