Beim 32. Treffen der Sofwerkskammer haben wieder gut 20 Interessierte den Weg gefunden. Dieses mal bei der Firma Lindenbaum die mit großartiger Gastfreundschaft aufwartete: Es gab Pizza für alle!
Das Thema Continuous Delivery (CD) hatte ich beim letzten Treffen spontan vorgeschlagen, nachdem Nicole nach einem Thema für das nächste Treffen gefragt hatte.
Meine Präsentation (Folien siehe unten) war darauf angelegt einen schnellen Einstieg zu geben um eine Diskussion anzustoßen.
Noch vor der eigentlichen Präsentation machten wir eine Vorstellungsrunde, bei der auch jeder ein paar Worte zum Thema CD sagte.
Bereits aus der Vorstellungsrunde ergab sich der erste Diskussions-Stoff. Einige äußerten sich dahin gehend das es sich für sie sehr riskant anhört jede Änderung auszuliefern. Andere vertraten die Meinung das es dem Kunden zu viel wird wenn er ständig neue Software ausgeliefert bekommt.
Genau hier wurde Continuous Delivery mit Continuous Deployment verwechselt. Bei Continuous Delivery geht es nicht darum jede Änderung automatisch Auszuliefern. Es geht viel mehr darum sich so zu organisieren, dass jede Änderung ein Release Candidate ist und mit einem Knopfdruck ausgeliefert werden könnte.
Martin Fowler schreibt zu Continuous Delivery: "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time."
Carl Caum (Product Owner bei PuppetLabs) hat speziell zum Thema Continuous Delivery vs. Continuous Deployment einen sehr informativen und anschaulichen Blog geschrieben: Continuous Delivery Vs. Continuous Deployment: What's the Diff?
Eine besonders interessante Diskussion entstand als ich Continuous Integration als Vorraussetzung für Continuous Delivery angesprochen habe.
Es stellte sich heraus, dass die konkrete Anwendung von CI in mehreren Interpretationen gelebt wird.
Konkret ging es darum ob Akzeptanztests am Anfang eines Sprints gleich scharf gestellt werden und während des Sprints darauf hingearbeitet wird alle Tests grün zu bekommen.
Dagegen stellte sich Jez Humbles Erklärung was CI ist. Der wichtige Teil: So lange der Build oder die Tests fehlschlagen darf keiner weiterarbeiten, es sei den er löst das Problem. Das heißt das der Build zu jedem Zeitpunkt lauffähig sein muss.
Die Diskussion erweiterte sich dann dahingehend wie was in der Praxis umgesetzt werden kann, denn alle waren sich einig das Akzeptanztests geschrieben werden sollten. Eine mögliche Lösung war hierbei das nutzen von "Ignore" (sofern ein derartiges Feature vom verwendeten TestRunner unterstützt wird). Das heißt alle Akzeptanztests werden geschrieben, aber so lange beim zentralen Build Ignoriert, bis die Implementierung fehlerfrei läuft. Lokal kann die Lauffähigkeit mittels dem Akzeptanztests überprüft werden.
Insgesamt wieder eine sehr informative und lebhafte Veranstaltung.
Nochmal vielen Dank an Lindenbaum und Rusi für den riesigen Service!
Cheers,
Christoph
Folien: Herunterladen
Aufnahme: Coming soon ...
Video: Continuous Delivery with Jez Humble
Buchtipp: