Kontinuierliche Lieferung

Wie der Name schon sagt, ist kontinuierliche Lieferung eine Praxis der Softwareentwicklung, die in Verbindung mit kontinuierlicher Integration eingesetzt wird, um den Release-Prozess einer Anwendung zu automatisieren. Softwareentwickler(innen) veröffentlichen Code-Updates in kurzen, aber kontinuierlichen Zyklen und nutzen die Automatisierung, um die Veröffentlichung zu beschleunigen. Zu CD gehören alle Schritte im Produktionszyklus – Erstellen, Testen, Konfigurieren und Bereitstellen. Das ultimative Ziel ist es, Software an die Benutzer(innen) zu übergeben.

CD kann als Erweiterung der kontinuierlichen Integration betrachtet werden, was manchmal auch als CI/CD bezeichnet wird. Dabei handelt es sich um die Praxis, Code in ein gemeinsames Repository zu integrieren und jede Änderung so schnell wie möglich, automatisch und in der Regel mehrmals am Tag zu erstellen und zu testen.

Nachdem die kontinuierliche Integration den Code in einem gemeinsamen Repository erstellt und getestet hat, übernimmt die kontinuierliche Lieferung die letzten Schritte, um sicherzustellen, dass die Softwareversionen risikoarm, konsistent und wiederholbar sind.

Der Begriff kontinuierliche Lieferung (Continuous Delivery) wird oft synonym mit dem Begriff kontinuierlichen Bereitstellung (Continuous Deployment) verwendet, aber es gibt einen feinen Unterschied zwischen den beiden. Bei der kontinuierlichen Bereitstellung wird der gesamte CI-validierte Code automatisch in die Produktion übertragen, während kontinuierliche Lieferung bedeutet, dass dieser Code bereitgestellt werden kann. Die Flexibilität, dass der Code jederzeit bereitgestellt werden kann, unterscheidet die Lieferung von der Bereitstellung, und die Umsetzung der kontinuierlichen Bereitstellung ist möglich, wenn die kontinuierliche Lieferung bereits vorhanden ist.

Für die Entwicklungsteams ergeben sich viele weitere Vorteile, wenn sie Software durch den Lebenszyklus der Softwareentwicklung (SDLC) liefern. Dazu gehören:-

• Automatisierung des Software-Release-Prozesses

• Geringere Kosten als bei der traditionellen Softwareentwicklung

• Verbesserte Produktivität

• Schnelle Identifizierung und Behebung von Bugs

• Schnellere Markteinführung durch kontinuierliche Tests und Entwicklung

Releases sind risikoarm – also problemlos und langweilig. CD beseitigt auch Engpässe bei der Bereitstellung, damit die Pipeline bis zu den Endnutzer(inne)n fließt. Die Bereitstellung ist einfacher, weil der Code bei Bedarf ausgerollt und zurückgesetzt werden kann.

CD wird oft zusammen mit DevOps angewendet und produziert Software in kurzen Zyklen. Auf diese Weise können Teams Software häufiger erstellen, testen, konfigurieren und veröffentlichen. Der Code wird umfassenden Tests unterzogen, um sicherzustellen, dass alle Funktionen funktionieren und unerwartete Leistungsprobleme in der Produktion vermieden werden. Jede Komponente, die die automatisierten Tests erfolgreich durchläuft, ist ein gültiger Kandidat für die Veröffentlichung. In der letzten Phase erfolgt eine abschließende Überprüfung durch eine(n) Entwickler(in), bevor es an die Bereitstellung geht.

Phasen: Erstellen, Testen, Konfigurieren und Bereitstellen

Workflows: Normalerweise schreibt ein(e) Entwickler(in) Code und checkt den Code mithilfe eines Versionskontrollsystems oder eines Konfigurationsverwaltungstools ein. Dann wird er erstellt und in ein Artefakt verpackt, das in einem Repository gespeichert wird.

Umgebungen: Dies ist die Zielinfrastruktur für die Bereitstellung und kann ein Kubernetes-Cluster, eine öffentliche Cloud-Instanz oder ein privates, lokales Rechenzentrum sein.

Pipelines: Typische Pipelines umfassen Bereiche wie automatisierte Builds, Tests und Staging-Bereitstellungen in einem kontinuierlichen Prozess.

Trigger: Ein Trigger startet ein Ereignis, das den Pipeline-Prozess auslöst. Ein Trigger kann manuell oder in der CI/CD-Pipeline automatisiert sein. Das könnten beispielsweise ein neues Artefakt oder ein Zeitintervall sein.

Eines der wichtigsten Merkmale einer automatisierten CD-Pipeline ist die Möglichkeit, automatisierte Tests und Veröffentlichungen durchzuführen. Die Testphase sollte sowohl funktionale als auch nicht-funktionale Tests umfassen. Eine Pipeline, die für Releases automatisiert ist, ermöglicht einen „Fail Fast“-Ansatz, bei dem die Tests, die am ehesten fehlschlagen, zuerst ausgeführt werden.

Eine automatisierte Pipeline bietet auch Einblick in den Code und erhöht das Vertrauen in seine Funktionsfähigkeit, während er die verschiedenen Phasen der CD durchläuft.

Mit einer automatisierten Softwarebereitstellungspipeline entfallen manuelle Aufgaben, die oft fehleranfällig und teuer sind. Außerdem können Teams Code erkennen, der nicht bereit für die Bereitstellung ist, und diesen ablehnen, um dann schnell Feedback zu geben.

Die Sicherheit sollte im SDLC nicht zu kurz kommen. Der Schlüssel dazu ist, dass die Sicherheits- und Entwicklerteams miteinander kommunizieren und zusammenarbeiten, um ihre unterschiedlichen Prioritäten und Ziele zu verstehen.

Wenn die Continuous-Delivery-Mentalität auf Sicherheitstests angewendet wird, wird der Prozess rationalisiert und die Belastung der Sicherheitsteams verringert. Jeder neue Programmteil, der in kontinuierlichen Release-Modellen bereitgestellt wird, kann schneller überprüft werden, wodurch Fehler leichter gefunden und behoben werden können.

Das Fließbandmodell der Anwendungsentwicklung ist nicht mehr praktikabel. Wenn Sicherheitsteams warten müssen, bis eine Anwendung fertig ist, bevor sie Sicherheitslücken beheben können, werden sie niemals mit der Geschwindigkeit und der Nachfrage nach Innovationen mithalten können.

Um CD in vollem Umfang zu nutzen, müssen die Teams während des gesamten DevSecOps-Prozesses in ständiger Kommunikation und Zusammenarbeit stehen. Das erfordert ein Umdenken, damit Entwickler(innen) und Sicherheitsteams die Vorteile nutzen können.

Die kontinuierliche Lieferung ist eine Praxis der Softwareentwicklung, bei der die Software so erstellt wird, dass sie jederzeit für die Produktion freigegeben werden kann. Sie fungiert innerhalb von DevOps als Stützpfeiler der Brücke, die die Lücke zwischen Entwickler(inne)n und IT-Betriebs-Teams schließt.

DevOps ist eine Softwareentwicklungsstrategie, die die Lücke zwischen den Entwicklungs- und IT-Betriebsteams in einem Unternehmen schließt. Eine DevOps-Kultur bricht die Isolationsmentalität auf und verbindet Menschen, Prozesse und Technologien, um die Zusammenarbeit und Koordination zu verbessern. Der Prozess wird verwendet, um eine neue Funktion, eine Verbesserung oder eine Codeänderung so schnell wie möglich in die Produktion zu bringen und die Kund(inn)en zu erreichen.

Der Prozess der Softwarebereitstellung ist jedoch nach wie vor komplex – selbst wenn Entwicklungs-, IT-Betriebs-, Qualitätsentwicklungs- und Sicherheitsteams im Rahmen von DevOps eng zusammenarbeiten. DevOps gliedert die Softwarebereitstellung in mehrere Phasen: Planen, Entwickeln, Liefern, Bereitstellen und Betreiben.