Was ist Continuous Delivery?

Das Herzstück von DevOps ist eine veränderte Mentalität. Anstatt die Softwareentwicklung als Einweg-Förderband zu betrachten, bei dem Anforderungen, Code und Berichte linear von einem Team an das nächste weitergereicht werden, geht es bei DevOps um Zusammenarbeit und schnelles Feedback mittels kurzer, iterativer Zyklen.

Wenn wir diese Mentalität übernehmen wollen, hilft es, wenn wir unsere Definition von „fertig“ überdenken: Statt unseren Beitrag als abgeschlossen zu betrachten, sobald wir unseren Code an das nächste Team in der Kette übergeben haben, gilt unser neues Feature oder unsere Codeänderung erst dann als fertig, wenn das Release veröffentlicht wurde. Wenn an irgendeinem Punkt in der Pipeline ein Problem auftritt, wird durch sofortiges Feedback und gemeinsame Korrekturarbeit schneller eine Lösung gefunden als durch langwierige Berichte, die über ein Change Board übermittelt und genehmigt werden müssen. Darum geht es bei der Continuous Delivery.

Wenn wir den gesamten Softwareentwicklungszyklus und nicht nur einen Teil davon im Blick haben, erhalten wir einerseits ein besseres Verständnis dafür, was zur Bereitstellung der Software an die Nutzer*innen erforderlich ist, und andererseits eröffnen wir neue Kommunikationswege zu den anderen beteiligten Teams.

Bei Continuous Delivery geht es darum, die Schwachstellen zu identifizieren, die diesen Bereitstellungsprozess verlangsamen, und eine automatisierte Pipeline aufzubauen, um Releases schneller und zuverlässiger veröffentlichen zu können, sodass wir jederzeit releasebereit sind. Wenn unsere Pipeline eingerichtet ist, sollten wir in der Lage sein, jeden „guten“ Build mit einem einzigen Befehl in ein Release zu verwandeln.

Die Grundlagen dafür werden durch Continuous Integration gelegt. Commits von Codeänderungen erfolgen mindestens einmal täglich, gefolgt von einem automatisierten Build- und Testprozess, der Entwicklern schnelles Feedback gibt. Wenn ein Build oder Test fehlschlägt, hat die Problemlösung für alle Beteiligten Priorität.

Indem wir Bugs frühzeitig erkennen, können wir sie beheben, während der Code noch frisch in unserem Gedächtnis ist. Außerdem vermeiden wir dadurch, dass weitere Features auf dem fehlerhaften Code aufgebaut werden, nur um ihnen später die Grundlage zu entziehen. Bei Continuous Delivery durchläuft der Build mit den neuesten aus dem CI-Prozess stammenden Änderungen automatisch eine Reihe von Vorproduktionsumgebungen. Der endgültige Push zur Produktionsphase erfolgt zwar manuell, aber der Ablauf folgt einem geskripteten Prozess, sodass er leicht wiederholt werden kann und dadurch Releases im gewünschten Abstand ermöglicht.

Der Aufbau einer CI/CD-Pipeline ist eine Gelegenheit für den Austausch mit den verschiedenen Stakeholdern im Releaseprozess, um ihre Anforderungen bei der Pipeline-Gestaltung berücksichtigen zu können. Beim Entwurf automatisierter Tests sollten wir uns zum Beispiel erst mit den Kolleg*innen in der Qualitätssicherung austauschen.

Durch Hinzufügen einer Phase für manuelles, exploratives Testen in einer geeigneten Testumgebung (so nah wie möglich an der Produktionsumgebung) können Fehler identifiziert werden, mit denen man nicht gerechnet hat (und die dann durch automatisierte Tests abgedeckt werden können). Das ist ein wichtiger Schritt für die Continuous Delivery.

Aufgrund der Verzögerungen durch Sicherheitsaudits und die anschließenden langwierigen Berichte gilt das Infosec- oder Cybersecurity-Team oft als Hindernis für häufige Releases. Hier hilft der DevSecOps-Ansatz, um Sicherheitsanforderungen direkt in die Pipeline zu integrieren.

Die genauen Build-Schritte, Umgebungen und Tests, die wir benötigen, hängen von der Architektur unserer Software und unseren organisatorischen Prioritäten ab. Wenn wir ein auf Microservices basierendes System entwickeln, können wir die Architektur nutzen, um einzelne Services parallel zu testen, bevor die Services für komplexere Integrations- und End-to-End-Tests kombiniert werden.

Manuelles, exploratives Testen für jeden Bugfix, der die Pipeline durchläuft, erscheint oft übertrieben. In solchen Fällen kann es effizienter für Continuous Delivery sein, je nach Art der Änderung optionale Schritte oder alternative Pipelines zu verwenden.

Sobald wir die Phasen unserer Pipeline festgelegt haben, einschließlich der Tests, die in den einzelnen Phasen ausgeführt werden sollen, wird es Zeit, den Prozess zu skripten, um Zuverlässigkeit und Reproduzierbarkeit zu gewährleisten. Um Inkonsistenzen zu vermeiden, sollten Build-Artefakte aus der CI-Phase in identischer Form in den einzelnen Vorproduktionsumgebungen und in der Produktion selbst eingesetzt werden.

Im Idealfall sollte für jeden neuen Build eine frische Testumgebung bereitgestellt werden. Beim Einsatz von Containern im Rahmen eines Infrastruktur-als-Code-Ansatzes können wir diese Schritte skripten und neue Umgebungen nach Bedarf errichten und entsorgen.

Wenn Ihre Pipeline Staging-Umgebungen für Support-, Vertriebs- oder Marketingteams umfasst, um eine Einarbeitung in neue Features ermöglichen, kann es sinnvoll sein, die Aktualisierung dieser Umgebungen mit neuen Builds manuell zu steuern, um zu verhindern, dass laufende Arbeitsvorgänge unterbrochen werden. Trotzdem kann die Bereitstellung genauso wie beim Release einer Produktionsversion geskriptet werden, um einen schnellen und reproduzierbaren Prozess zu gewährleisten.

Continuous Delivery verspricht schnellere Releases ohne Qualitätskompromisse. Um dies zu verwirklichen, ist jedoch eine Zusammenarbeit verschiedener Bereiche im Unternehmen erforderlich.

Der Abbau von Silos – isolierten Bereichen im Unternehmen – ist zwar kurzfristig eine Herausforderung, aber langfristig ein Vorteil, denn diese Art der Kooperation ermöglicht effektiveres Arbeiten.

Die Implementierung von Continuous Delivery erfordert einiges an Zeit und erscheint im Vorfeld oft als Herkulesaufgabe. Wenn Sie Ihre Prozesse jedoch mithilfe eines iterativen Ansatzes Schritt für Schritt aufbauen, ist der Vorgang leichter zu handhaben, und die Vorteile können der Unternehmensführung einfacher vermittelt werden. Die Erfassung von Build- und Testzeiten und der Vergleich mit manuellen Verfahren ist eine einfache Methode zur Quantifizierung der Investitionsrendite. Ähnliches gilt für die Entwicklung der Fehlerquoten.

Die Messung des Wertbeitrags der Continuous Delivery kann bei der Planung der Infrastrukturanforderungen hilfreich sein. Beim Hochskalieren des Releaseprozesses will man in der Regel mehrere Builds und Tests gleichzeitig ausführen, und die verfügbaren Computerressourcen können zu einem Flaschenhals werden. Sobald die Leistung der Pipeline optimiert wurde, lohnt es sich daher, über einen Wechsel zu einer Cloud-gehosteten Infrastruktur nachzudenken, um bei Bedarf ohne Einschränkungen skalieren zu können.

Eine CI/CD-Pipeline einzurichten kann auf den ersten Blick als eine Herausforderung erscheinen, die dem Team viel Vorarbeit abverlangt. Mit dem richtigen CI/CD-Ansatz kann Ihr Team jedoch 90% des Zeitaufwands beim Einrichten des Software-Bereitstellungsprozesses einsparen. Um optimal vorgehen zu können, sollten Sie jedoch einige CD-bezogene Best Practices berücksichtigen.

Continuous Delivery ist ein Prozess zur Automatisierung der verschiedenen Schritte, die erforderlich sind, um Software für den Produktionseinsatz fertigzustellen. Dies bedeutet jedoch nicht, dass die Software vollständig automatisiert bereitgestellt wird – hier kommt Continuous Deployment ins Spiel. Wir können Continuous Delivery und Continuous Deployment als unterschiedliche Teile desselben CI/CD-Prozesses betrachten.

Mehr zum Unterschied zwischen Continuous Delivery und Continuous Deployment

Continuous Delivery erleichtert und beschleunigt die Bereitstellung von Software-Releases, sodass Sie die Releasefrequenz Ihrer Produktionsversionen hochfahren können. Anstelle eines großen vierteljährlichen oder jährlichen Updates können häufig kleinere Updates bereitgestellt werden. Dies bedeutet nicht nur, dass Ihre Kunden schneller von neuen Funktionen und Fehlerkorrekturen profitieren. Sie erhalten darüber hinaus auch einen Einblick in die Nutzung Ihrer Software „in freier Wildbahn“ und können Ihre Pläne entsprechend anpassen.

Während einige Organisationen lieber die Kontrolle über den letzten Schritt des Releaseprozesses behalten wollen, besteht für andere die logische Konsequenz einer CI/CD-Pipeline darin, mit einer Methode namens Continuous Deployment auch die Veröffentlichung von Produktionsreleases zu automatisieren.