Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein “Deploy”-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.
Was Continuous Deployment tatsächlich ist#
Mit Continuous Deployment wird jede Änderung, die die CI-Checks und die Staging-Tests besteht, automatisch in Produktion deployed. Die Pipeline ist der Release-Prozess. Es gibt kein separates Release-Event, kein manuelles Approval, kein “sind wir bereit?"-Meeting. Sind die Tests grün, ist Produktion aktualisiert.
Die Auswirkungen sind enorm. Ein Entwickler, der um 10:14 eine kleine Änderung committet, sieht diese Änderung um, sagen wir, 10:32 live bei den Kunden. Der Feedback-Loop schliesst sich in Minuten. Die Kosten, eine einzelne Änderung zu releasen, sinken auf fast null — und die Folge ist, dass die Änderungseinheit winzig wird. Winzige Änderungen sind leicht zu debuggen, leicht zurückzurollen und leicht zu verstehen.
Continuous Deployment vs. Continuous Delivery#
Diese Unterscheidung ist wichtig und wird ständig verwischt:
- Continuous Delivery endet bei Staging. Das Artefakt ist nachweislich releasebar; ein Mensch entscheidet, wann released wird.
- Continuous Deployment geht den ganzen Weg bis Produktion. Es gibt kein menschliches Gate.
Beide werden CD abgekürzt. Wenn jemand sagt “wir machen CD”, frag nach, was gemeint ist. Wenn es irgendein manuelles Approval vor Produktion gibt, machst du Continuous Delivery, nicht Continuous Deployment. Beides ist legitim; das eine fürs andere zu halten, ist es nicht.
Was Continuous Deployment verlangt#
Continuous Deployment ist nicht nur eine Tooling-Änderung. Es verlangt ein Mass an Disziplin, das die meisten Organisationen unterschätzen:
- Testabdeckung, der man wirklich vertraut. Wenn du das Geschäft nicht auf die Test-Suite verwetten würdest, lass sie nicht unbeaufsichtigt deployen. Continuous Deployment legt jede Lücke in den Tests direkt vor die Kunden.
- Schnelles, zuverlässiges Rollback. Es wird etwas durchrutschen. Die richtige Antwort ist nicht “wir hören auf zu deployen”, sondern “wir machen Rollback schneller als das nächste Deploy”.
- Monitoring und Alerting, das in Minuten reagiert. Wenn du Dutzende Male pro Tag deployst, kannst du nicht warten, bis der Support meldet, dass etwas kaputt ist.
- Feature Toggles, um Deployment vom Release zu trennen. Code kann in Produktion sein, ohne für Nutzer sichtbar zu sein. Genau das macht das Deployment wirkungsstarker Änderungen sicher.
- Kleine, fokussierte Commits. Big-Bang-Änderungen und Continuous Deployment vertragen sich nicht. Das ganze Modell setzt voraus, dass die Änderungseinheit klein ist.
Fehlt eines dieser Stücke, ist Continuous Deployment nicht aggressiv — es ist fahrlässig.
Warum sich Continuous Deployment auszahlt#
Wenn es funktioniert, kumuliert sich der Effekt. Releases werden zum Nicht-Ereignis. Hotfixes gehen in Minuten raus, statt auf ein Release-Fenster zu warten. Experimente sind günstig, also macht das Team mehr davon. In Produktion gefundene Bugs sind schneller gefixt und deployed, als sie in einem langsameren Modell triagiert werden könnten. Time-to-Market kollabiert für die Dinge, die wirklich zählen.
Das meistzitierte Beispiel ist Amazon, das bekanntermassen tausende Male pro Tag über seine Services deployed. Der Punkt ist nicht die absolute Zahl — der Punkt ist, dass Releases so routiniert geworden sind, dass niemand mehr darüber nachdenkt. Die Aufmerksamkeit des Teams geht dahin zurück, wo sie hingehört: Dinge zu bauen, die Kunden interessieren.
Wann du Continuous Deployment nicht machen solltest#
Continuous Deployment ist nicht immer die richtige Antwort. Regulierte Umgebungen verlangen unter Umständen aus Compliance-Gründen ein explizites menschliches Sign-off. Mobile Apps durchlaufen Store Approval — es gibt kein “Auto-Deploy in den App Store”. Koordinierte Marketing-Launches brauchen einen kontrollierten Release-Moment. In allen diesen Fällen ist Continuous Delivery mit einem manuellen Release-Button das richtige Modell. Sei ehrlich mit deinen Rahmenbedingungen; jag Continuous Deployment nicht als Statussymbol hinterher.
Key Takeaways#
- Continuous Deployment entfernt das letzte manuelle Gate. Jede bestandene Änderung geht automatisch in Produktion.
- Es ist nicht dasselbe wie Continuous Delivery. Delivery endet bei Staging; Deployment geht den ganzen Weg. Die Trade-offs sind unterschiedlich.
- Die Änderungseinheit muss klein sein. Grosse Releases und Continuous Deployment sind unvereinbar.
- Tests, Rollback und Monitoring müssen stehen, bevor du den Schalter umlegst. Ohne sie ist automatisches Deployment automatischer Schaden.
- Trenne Deployment vom Release mit Feature Toggles. Code in Produktion muss nicht heissen, dass Features für Nutzer sichtbar sind.
- Es ist nicht immer das richtige Ziel. Regulierung, Store Approval oder koordinierte Launches machen Continuous Delivery für manche Produkte zur besseren Antwort.