Continuous Integration, Delivery, Deployment: Was ist der Unterschied?

Dieses Mal bauen CI/CD bzw. Continuous Integration und Continuous Delivery/Continuous Deployment gut aufeinander auf. Alle drei stehen im Mittelpunkt dessen, was DevOps erreichen möchte. Es wird also Zeit, die Abkürzungen genauer zu betrachten.

Was ist Continuous Integration?

Der erste Schritt ist CI, die Abkürzung für Continuous Integration.

Bei Continuous Integration wird eine Codeänderung, sobald sie vom Entwickler vorgenommen und als bereit erklärt wurde, in ein Remote-Repository eingecheckt. Anschließend durchläuft der gesamte neue, geänderte Code auf einem Server eine Reihe automatisierter Tests. Diese Tests, darunter Regressionstests, stellen sicher, dass beim Hinzufügen oder Verbessern neuer Funktionen keine bestehende Funktionalität verloren geht.

Als Best Practice gelten jedoch abgesicherte Commits. Das bedeutet, dass der neu eingecheckte Code eines Entwicklers getestet wird, bevor er mit anderen Entwicklern oder Testern geteilt wird. Das fördert kleine Änderungen, die häufig zusammengeführt werden. Dadurch bleiben Änderungen überschaubar, und der Zustand der Software verbessert sich kontinuierlich, weil der neue Code getestet wird.

Um eine Abschlussarbeit von einem Eficode-Mitarbeiter zu zitieren: „Continuous Integration wurde entwickelt, um den Problemen \[eines\] sequenziellen Modells der Softwareentwicklung entgegenzuwirken. Nachdem die Phasen Anforderungen, Analyse, Design und Implementierung abgeschlossen waren, traten in der Integrationsphase eines Softwareprojekts häufig erhebliche Probleme auf.“ (Seite 11)

Zusammengefasst bedeutet Continuous Integration, neuen Code häufig beizutragen. Heute löst dies in den meisten Fällen automatisierte Tests aus. Nach Ansicht vieler ist sie eine Voraussetzung für CD bzw. Continuous Delivery.

CI kommt somit früher im Prozess als Continuous Delivery und Continuous Deployment, auf die wir als Nächstes eingehen.

Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?

CD kann für Continuous Deployment oder Continuous Delivery stehen. Zwischen den beiden DevOps-Ansätzen gibt es nur einen kleinen Unterschied, und der liegt in der letzten Phase.

Deployment wird üblicherweise als die Bereitstellung einer Anwendung in einer bestimmten Umgebung definiert. In der Regel handelt es sich dabei um die Produktionsumgebung, auf die Benutzer zugreifen.

Wenn die Anwendung auf einer Website läuft oder von einer zentralen IT-Abteilung verwaltet wird, haben Benutzer keine andere Wahl, als sie zu nutzen. Ein Deployment kann dennoch Funktionen enthalten, die Benutzern nicht bekannt sind (sogenannte „Dark Launches“) und für ein zukünftiges Release getestet werden. Wie der Begriff schon sagt, wird ein Release öffentlich angekündigt. Bei herunterladbarer Software liegt es zudem mehr oder weniger in der Entscheidung des Benutzers, ob er sie ausprobieren möchte oder nicht.

Bei Continuous Delivery wird die Anwendung durch Abnahmetests in einer isolierten (Test-)Umgebung bis zu einem Punkt bereitgestellt, an dem das Deployment in die Produktion nur noch einen Klick entfernt ist. Meist steht hinter diesem Klick eine strategische Entscheidung des Managements.

Oder wie Severi Haverila von Eficode es in seiner Abschlussarbeit formulierte: „... das zentrale Prinzip von Continuous Delivery besteht darin, die Software kontinuierlich in einem bereitstellbaren Zustand zu halten.“ (Seite 11)

Continuous Deployment (oder automatisiertes Deployment) erfolgt automatisch bis zur Bereitstellung für Endbenutzer. Der technische Aufwand für beide CDs ist daher praktisch identisch: den vollständigen Deployment-Prozess automatisieren und die letzte Phase manuell steuerbar machen, wenn Continuous Delivery das Ziel ist.

Die Diskussion geht weiter!

Wie bei allen Definitionen – einschließlich der Definition von DevOps selbst – wird darüber diskutiert, welche Definition die maßgebliche ist.

Führende Tool-Anbieter wie Atlassian und Puppet scheinen zu einem ähnlichen Verständnis von CI/CD gelangt zu sein, das dem zuvor in diesem Text dargestellten entspricht.

Ob dies als De-facto-Definition gelten kann, lässt sich vielleicht noch nicht sagen. Wie alle anderen weit verbreiteten Begriffe müssen sie für den jeweiligen Anwendungsfall immer klar definiert werden.

In der Zwischenzeit werden sich die Studenten der Zukunft mit Abkürzungen befassen müssen, die noch entstehen. Die gesamte Branche scheint sich jedoch einig zu sein, dass CI/CD oder allgemeiner Automatisierung Entwickler und Betriebsteams näher zusammenbringt.

Das sollte letztlich dazu führen, dass entwickelte Software in kürzerer Zeit Mehrwert schafft.