Was ist Continuous Delivery (CD)?

Was ist Continuous Delivery (CD)?

Continuous Delivery ist eine Disziplin der Softwareentwicklung, bei der jede Änderung automatisch gebaut, getestet und weitergereicht wird, sodass die Software jederzeit in Produktion gehen kann. Martin Fowler beschreibt es genau so: Die Software "can be released to production at any time". Ob und wann tatsächlich released wird, bleibt eine Entscheidung von Menschen oder des Business. Die Praxis baut auf Continuous Integration auf und nutzt meist eine Deployment-Pipeline.

Continuous Delivery vs. Continuous Deployment

Beide werden mit "CD" abgekürzt, daher die Verwechslung. Fowlers Unterscheidung: Bei Continuous Deployment wird jede Änderung, die durch die Pipeline läuft, automatisch in Produktion gebracht. Bei Continuous Delivery könnten Sie oft deployen, entscheiden sich aber gegebenenfalls dagegen, etwa weil das Business einen langsameren Release-Rhythmus will. Continuous Deployment ist also Continuous Delivery plus ein automatischer letzter Schritt. Umgekehrt gilt das nicht.

So funktioniert eine Delivery-Pipeline

Eine Änderung durchläuft mehrere Stufen, und ein Fehler in einer Stufe stoppt sie:

1. Commit und Build. Ein Merge in den Hauptbranch löst einen Build aus, der ein einziges Artefakt erzeugt, etwa ein Container-Image.
2. Schnelle Tests. Unit-Tests und statische Prüfungen liefern Feedback in Minuten.
3. Deployment in eine produktionsnahe Umgebung. Dasselbe Artefakt wird weitergereicht und nie neu gebaut, damit ausgeliefert wird, was getestet wurde.
4. Langsamere Prüfungen. Hier laufen Integrations-, End-to-End- und Regressionstests, und auch ein Lasttest.
5. Release. Ein Mensch löst es aus (Delivery) oder die Pipeline (Deployment).

Zwei Techniken machen häufige Releases sicherer: Feature Flags trennen das Deployen von Code vom Einschalten einer Funktion, und ein schrittweiser Rollout begrenzt, wie viele Nutzer eine Änderung zuerst sehen.

Beispiel

Ein Team merged um 10:00 Uhr einen Pull Request. Um 10:15 Uhr hat die Pipeline ein Image gebaut, die Unit-Tests bestanden und auf Staging deployt, wo auch die End-to-End-Suite und ein kurzer Lasttest durchlaufen. Der Build gilt als releasefähig. Der Product Owner wartet auf die Marketing-Ankündigung und released am Donnerstag per Klick. Würde die Pipeline schon um 10:15 Uhr ohne diesen Schritt ausliefern, wäre es Continuous Deployment.

Häufige Fehler

• Den Build-Server "CD" nennen. Ohne automatisierte Tests und einen wiederholbaren Release-Schritt ist die Software nicht auf Abruf releasefähig.
• Pro Umgebung neu bauen. Ein anderes Artefakt in Produktion als auf Staging nimmt der Pipeline ihren Sinn.
• Langlebige Branches. Seltene Integration macht jedes Release groß und riskant.
• Manuelles Einrichten der Umgebungen. Ein Staging, das von Produktion abweicht, verbirgt Probleme bis zum Release-Tag. Infrastructure as Code hilft.
• Performance auslassen. Funktionale Tests bestehen, während eine Änderung die App unter Last langsam macht.

Continuous Delivery, Lasttests und Monitoring

Ein releasefähiger Build sollte auch unter Last bestehen. Die Lasttest-Seite von LoadFocus beschreibt eine GitHub Action, die einen Lasttest startet, das Pass/Fail-Ergebnis liest und ein Deployment blockieren kann, wenn ein Schwellenwert verletzt wird. Nach dem Release zeigt API-Monitoring, ob sich Produktion so verhält, wie die Pipeline es erwarten ließ. Praktische Hinweise zu Pipelines finden Sie in unseren CI/CD Best Practices (englisch) und im Leitfaden zu Canary Deployments (englisch).

Häufige Fragen

Ist Continuous Delivery dasselbe wie Continuous Deployment?

Nein. Continuous Delivery hält jede Änderung releasefähig und überlässt die Release-Entscheidung Menschen. Continuous Deployment bringt jede Änderung, die die Pipeline besteht, automatisch in Produktion.

Brauche ich zuerst Continuous Integration?

In der Praxis ja. Continuous Delivery baut auf Continuous Integration auf: Änderungen müssen häufig zusammengeführt und getestet werden, bevor sie weitere Stufen durchlaufen können.

Heißt Continuous Delivery, mehrmals täglich zu releasen?

Nein. Es heißt, dass Sie jederzeit releasen können. Wie oft Sie es tun, ist eine geschäftliche Entscheidung.

Wo gehören Lasttests in die Pipeline?

Nach dem Deployment in eine produktionsnahe Umgebung, als eine der langsameren Prüfungen. Ein Schwellenwert für Antwortzeit oder Fehlerrate kann den Build vor dem Release scheitern lassen.