Was man häufiger mal sieht, ist die Abkürzung „CI/CD“. Während wir inzwischen „CI“ in „Continuous Integration“ auflösen können, stehen uns für „CD“ mindestens zwei Möglichkeiten zur Verfügung „Continuous Delivery“ und „Continuous Deployment“. Sehen wir uns an, was hinter diesen Konzepten steckt?
Was ist Continuous Deployment?
„Continuous Deployment“ lässt sich mit fortwährender oder kontinuierlicher Auslieferung übersetzen. Die Idee ist hierbei, dass der Prozess der „Continuous Integration“ um die Auslieferung ergänzt wird.
Mithilfe von CI erhalten wir ein getestetes und für den produktiven Einsatz vorbereitetes Artefakt. Dieses Artefakt liefern wir nun aus. Das hat den Vorteil, dass Verbesserungen und Fehlerbehebungen im Code die Anwenderinnen und Anwender schnell erreichen, denn durch den hohen Grad an Automation erzielen wir eine hohe Geschwindigkeit. Das steigert zum einen die Zufriedenheit bei den Anwenderinnen und Anwender und zum anderen die Zufriedenheit bei den Entwicklerinnen und Entwicklern, denn diese spüren, dass ihre Arbeit ohne Reibungsverluste veröffentlicht wird und somit direkt einen Einfluss hat.
Was ist Continuous Delivery?
„Continuous Delivery“ ist dem Ganzen sehr ähnlich. Als Übersetzung bietet sich fortwährende oder kontinuierliche Übergabe an. Auch hierbei entsteht am Ende des CI-Prozesses ein fertiges Artefakt. Anders als beim Continuous Deployment jedoch gibt es bei der Continuous Delivery einen manuellen Zwischenschritt.
Worum geht’s eigentlich?
Continuous Integration, Continuous Deployment and Delivery haben im Grunde nur ein Ziel: In kürzeren Zyklen qualitativ hochwertige Software zu den Kunden zu bringen, ohne dabei das Entwicklungsteam außerordentlichen Belastungen auszusetzen.
Tatsächlich ist es in der Praxis nicht einfach, ein solches System aufzusetzen, das über längere Zeit reibungslos funktioniert. Es fallen durch fortlaufende Veränderungen wie beispielsweise Software-Aktualisierungen, neue Anforderungen, ablaufende Zertifikate, neue Buildrechner etc. unterschiedlicher Teile aus und müssen gepflegt werden. CI/CD sind wichtig, aber man muss sich vom Gedanken verabschieden, dass ein derartiger Workflow einmal etabliert wird und anschließend für immer wartungsfrei läuft.
Denn ein solches System ist unumgänglich, um über einen längeren Zeitraum auf einem hohen Niveau Software zu entwickeln und auszuliefern.
Worum es bei CI/CD nicht geht, ist, dass jede kleine Änderung am Code gleich zum Kunden verschifft wird. Es geht vielmehr darum, allzeit ein Artefakt zur Verfügung zu haben, das jederzeit voller Zuversicht an den Kunden ausgeliefert werden kann.
Wann passt Continuous Deployment oder Continuous Delivery nicht?
Es gibt auch Fälle, in denen der Workflow der beiden CDs nicht passt: Beispielsweise sind im medizinischen oder militärischen Bereich die Vorschriften so strikt, dass für derartige Prozesse, wie wir sie hier besprechen, kaum Raum bleibt.
Darüber hinaus gibt es manchmal auch unternehmenspolitische Vorgaben oder Marketingvorgaben, die es einzuhalten gilt und die somit einen vollautomatischen CI/CD-Prozess verhindern.
Fazit
Sowohl Continuous Deployment als auch Continuous Delivery setzen auf einen umfassenden und robusten Continuous-Integration-Prozess auf. Dieser liefert die Basis dafür, dass das erzeugte Artefakt von einer so hohen Qualität ist, dass die Auslieferung an die Kunden reibungslos funktionieren kann.
Schlussendlich geht es darum, die nervigen und fehleranfälligen Teile der Software-Auslieferung zu automatisieren. Ob das eine Team dies über Continuous Deployment das andere Team es über Continuous Delivery erreicht, spielt letztlich keine Rolle. Oft genug werden die beiden Begriffe auch synonym verwendet.
Möchte man einen erfolgreichen CI/CD-Prozess auf das Wesentliche reduzieren, endet man mit dem Leitsatz: Wir müssen alles auf jede erdenkliche Weise so gut automatisiert testen, dass wir voller Selbstvertrauen Software veröffentlichen können.
Photo by Matthew Henry from Burst