Wie unterscheidet sich Continuous Deployment von Continuous Delivery?
Bei Continuous Delivery ist die Software nach erfolgreichen Tests jederzeit auslieferbar, aber ein Mensch gibt den letzten Schritt frei. Continuous Deployment geht einen Schritt weiter: Jede Änderung, die alle Tests besteht, geht automatisch in Produktion, ohne manuelles Zutun. GitOps setzt genau hier an und macht den CD-Teil pull-basiert über Git.
Auch bekannt als: Kontinuierliches Deployment · Automatisches Deployment · CD
Ist Continuous Deployment bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Technisch ist Continuous Deployment eine Pipeline ohne Haltepunkt. Ein Merge in den Hauptbranch startet Build und Tests, danach laufen Quality Gates, und wenn alle bestanden sind, rollt die Pipeline die Änderung selbstständig in Produktion aus. Niemand klickt auf einen Freigabe-Button. Bei Continuous Delivery endet dieselbe Kette vor der Produktion und wartet auf eine Person.
Verantwortbar wird das nur mit Sicherheitsnetzen für Fehler, die trotzdem durchrutschen. Dazu gehören Canary Releases, die eine neue Version zuerst einem kleinen Teil des Traffics zeigen, und Feature Flags, die Funktionen im Code ein- und ausschalten. Hinzu kommen Monitoring mit klaren Schwellwerten und ein Rollback, der ohne manuelles Eingreifen funktioniert. Fehlen diese Bausteine, verlagert Continuous Deployment Fehler nur schneller zu den Nutzern.
Bei Web-Services ist Continuous Deployment verbreitet. In OT- und sicherheitskritischen Industrieumgebungen ist es dagegen oft weder erlaubt noch sinnvoll. Wartungsfenster, behördliche Freigaben und Safety-Nachweise stehen dagegen, und ein fehlerhaftes Update kann dort eine Maschine beschädigen statt nur eine Webseite. In diesen Umgebungen bleibt Continuous Delivery mit bewusster Freigabe das Ziel.
Ein häufiger Irrtum ist, Continuous Deployment als Tempo-Ziel zu betrachten. Die eigentliche Frage ist das Risikoprofil des Systems. Es passt für zustandslose Services, die sich in Sekunden zurückrollen lassen, und selten für Software, die physische Prozesse steuert. In unseren Projekten fahren Industrieunternehmen deshalb oft beides: automatisch für die Cloud-Backends, mit Freigabe für die Anlage.
SaaS-Anbieter lässt die Canary-Analyse über den Rollout entscheiden
Ein SaaS-Anbieter prüfte jedes Release früher in einer wöchentlichen Freigaberunde. Heute geht jeder gemergte Commit automatisch an fünf Prozent des Traffics. Bleiben Fehlerrate und Latenz im Budget, weitet eine Analyse-Komponente den Rollout stufenweise aus, sonst rollt sie zurück. Die Freigaberunde gibt es nicht mehr.
Dieselbe Pipeline hält vor der Anlagensteuerung an
Ein Maschinenbauer deployt seine Cloud-Backends vollautomatisch. Für Deployments auf Anlagensteuerungen hat er in derselben Pipeline eine manuelle Freigabe eingebaut, die nur innerhalb eines Wartungsfensters wirkt. Build, Tests und Artefakt sind identisch, nur der letzte Schritt wartet auf eine Person.
Continuous Delivery oder Continuous Deployment?
Der Unterschied ist die letzte Meile: Delivery hält ein Freigabe-Gate, Deployment geht vollautomatisch bis in die Produktion. Was zu Ihnen passt, hängt an Test-Vertrauen und Regulatorik.
Wie soll die letzte Meile laufen?
- Ist Continuous Deployment für jedes Team das Ziel?
- Nein. Es ist eine bewusste Entscheidung, die vom Risikoprofil abhängt. Für zustandslose Services mit schnellem Rollback passt es gut, für sicherheitskritische OT-Systeme mit physischer Wirkung ist Continuous Delivery mit manueller Freigabe meist die richtige Wahl.
- Welche Voraussetzungen muss ich erfüllen, bevor ich Continuous Deployment einführe?
- Sie brauchen eine belastbare automatisierte Teststrecke, Monitoring mit definierten Alarmschwellen, einen automatisierten Rollback und idealerweise Feature Flags, um Deployment und Release zu trennen. Ein guter Test ist die Frage, ob Sie ein fehlerhaftes Release heute ohne Handarbeit in wenigen Minuten zurückholen könnten. Lautet die Antwort nein, ist Continuous Delivery der nächste Schritt.
- Wie entkoppele ich Deployment von der Sichtbarkeit einer Funktion?
- Über Feature Flags. Der Code geht unsichtbar in Produktion und wird erst aktiv, wenn das Team das Flag umschaltet. So sind häufige Deployments möglich, ohne dass jede Änderung sofort für alle Nutzer wirkt.
Wo steht Ihr Team bei Continuous Deployment?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Continuous Deployment: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Martin FowlerContinuous Delivery(externe Seite, öffnet in neuem Tab)
Zieht die Trennlinie zwischen jederzeit auslieferbar und automatisch ausgeliefert.
- /02DORACapability: Continuous Delivery(externe Seite, öffnet in neuem Tab)
Forschungsbasierte Beschreibung der Praxis samt Wirkung auf Durchsatz und Stabilität.
- /03DORACapability: Deployment Automation(externe Seite, öffnet in neuem Tab)
Was ein vollautomatischer Deployment-Schritt voraussetzt und woran er in der Praxis scheitert.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance