@JUG_DA: Von Continuous Integration zu Continuous Delivery

Bevor ich mich die nächsten zwei Tage auf der JAX rumtreibe, wollte ich endlich noch meinen Beitrag zum letzten JUG-Treffen in Darmstadt leisten. Das Thema des Abends war "Von Continuous Integration zu Continuous Delivery" und wurde vorgestellt von Steffen Schluff. Nebenbei bemerkt sieht man daran mal wieder wie klein die Welt doch ist, denn Steffen war ein Kollege von einer meiner Kommilitoninnen. ;)

CI/CDSteffen hat seinen Vortrag begonnen mit einem kurzen Überblick über das prinzipielle Setting, wie es wahrscheinlich jeder Entwickler heute kennt. Continuous Integration gehört inzwischen ebenso zum guten Ton wie Versionierung. Das Thema Continuous Delivery hat er dann mit einem Zitat aus dem Agilen Manifest begonnen: "our highest priority is to satisfy the customer." Denn hier lieg der Kern der aktuellen Diskussion: Der Kunde ist im heutigen "Entwicklerkosmos" nicht vertreten. Neue Features oder Fixes werden erst mit einem Release ausgeliefert, welches mitunter einige Wochen oder Monate auf sich warten lässt. Die Idee von Continuous Delivery ist es, dem Kunden eben jene Verbesserungen sofort bereitzustellen: "Ship your product whenever you want." (Neal Ford)

Die Wurzeln von Continuous Delivery liegen im Agilen Manifest, der sogenannten Deployment Pipeline und dem Continuous Deployment. Die wichtigsten Kerngedanken sind (mMn) "bring the pain forward", "automate almost everything" und "done means released". Hauptaugenmerk wird beim Continuous Delivery auf Automation und Kollaboration gelegt. (Ich mag ja Kollaboration, so ein schönes Buzzword. ;)) Was damit gemeint ist, ist grundsätzlich die engere und damit hoffentlich bessere Zusammenarbeit der Teams von Entwicklung und Betrieb, Stichwort DevOps.

Die Deployment Pipeline ist prinzipiell eine stark minimalisierte Form der normalen Auslieferung. Sie beginnt mit der Commit Stage, ausgelöst durch einen Entwickler, durchläuft einige Testetappen und landet am Ende beim Release. Das alles funktioniert zum Teil automatisch, zum Teil müssen einzelne Stages durch manuelle Überprüfung (4-Augen-Prinzip) abgeschlossen werden. Das interessante ist, dass pro Commit eine Pipeline-Instanz läuft, welche u.U. bei Fehlern in den Testläufen abbricht oder, wenn alles gut läuft, mit der Auslieferung einer neuen Version endet. Wichtig sind hier vor allem Tests und das ist vermutlich so das Hauptproblem an vielen Stellen - die gibt's nämlich selten bis gar nicht. (Schlimm genug.)

Ein interessanter Aspekt ist außerdem noch das Configuration Management, bei welchem auch die Infrastruktur, bspw. das Zielsystem bzw. dessen Konfiguration, als Code angesehen wird und damit auch versioniert und automatisiert erstellt werden kann.

Continuous Delivery ist also scheinbar das nächste mehr oder weniger große Ding in der Entwicklerwelt. Aber auch hier, wie bei so vielen anderen schönen Sachen, stellen sich einige Probleme. Unter anderem: Wie bringe ich alle Leute des hier angestrebten, vergrößerten Personenkreises unter einen Hut - Geschäft, Entwicklung, Betrieb?

Bleibt spannend. Die Folien vom Vortrag gibt es übrigens hier und wer Steffen noch mal live sehen möchte, kann das am Donnerstag auf der JAX tun. Schaut auch noch mal bei Jörn vorbei, der war wieder schneller mit seinem Bericht und hat noch ein paar mehr Bilder. (Das Foto hier habe ich übrigens vom Twitter-Stream der JUG gemopst.)