Continuous Deployment (CD) ist die konsequente Erweiterung von Continuous Delivery: Jede Änderung, die alle automatisierten Qualitätsstufen einer Pipeline passiert, wird ohne manuelle Freigabe automatisch in Produktion gebracht. Während Continuous Delivery den Zustand "jederzeit deploybar" garantiert, automatisiert Continuous Deployment auch den letzten Schritt — den eigentlichen Rollout in die Live-Umgebung. Voraussetzung ist eine sehr hohe Test- und Beobachtbarkeitsabdeckung sowie sichere Rollout-Strategien wie Feature Flags, Canary Releases und schnelle Rollbacks.
Eingesetzt wird Continuous Deployment vor allem bei Web-SaaS-Anbietern, in Microservice-Landschaften und in Plattformprodukten, deren Risikoprofil und Architektur das zulässt. Klassische Vertreter sind Etsy, Netflix, Facebook (heute Meta), GitHub, Spotify, Amazon, Booking.com — Unternehmen, die im Tagesdurchschnitt hunderte oder tausende Deployments durchführen. In stärker regulierten Bereichen (Banken, Medizintechnik, kritische Infrastruktur) ist Continuous Deployment seltener, weil regulatorische Anforderungen explizite Freigaben verlangen; dort bleibt es bei Continuous Delivery mit manueller Produktionsfreigabe.
Manuelle Freigaben werden in der Praxis häufig zu Engpässen — Termine, Change-Advisory-Boards, "Wartungsfenster". Diese Reibung führt zu größeren, riskanteren Releases, die wiederum mehr manuelle Freigaben rechtfertigen. Continuous Deployment durchbricht diesen Kreis: Wenn ohnehin jede Änderung sofort live geht, müssen Pipeline und Beobachtbarkeit so gut sein, dass Fehler binnen Minuten bemerkt und behoben werden können.
Historisch wurde der Begriff in Buchform durch Jez Humbles und Dave Farleys "Continuous Delivery" (2010) systematisch behandelt; den Schritt zur vollständigen Automatisierung des Produktions-Rollouts haben insbesondere Internet-Unternehmen wie IMVU (mit ihrem dokumentierten Praxisbericht von Timothy Fitz, 2009: "Continuous Deployment at IMVU: Doing the impossible fifty times a day"), Etsy und Facebook in den späten 2000er-Jahren etabliert. Heute ist Continuous Deployment fester Bestandteil der DORA-Metriken — insbesondere "Deployment Frequency" und "Lead Time for Changes" — und gilt als ein Leitindikator für "Elite-Performer"-Engineering-Organisationen.
Prägendende Figuren sind Jez Humble, Dave Farley, Martin Fowler, Timothy Fitz (IMVU), John Allspaw und Mike Brittain (Etsy). Tim Fitz hat in seinem oft zitierten Artikel zu IMVU bemerkenswert nüchtern beschrieben, dass es in einem Continuous-Deployment-Setup keinen "Deployment-Tag" und keine "Release-Notes" im klassischen Sinn mehr gibt — die Dokumentation findet stattdessen pro Pull Request statt. Diese Verschiebung von "Release-Event" zu "permanenter Mikro-Auslieferung" ist eine der tieferen kulturellen Veränderungen der DevOps-Bewegung.
Bei bluehands beobachten wir immer in Softwaremodernisierungs-Projekten diesen Schwerz des Deployments. Einer der ersten Maßnahmen ist immer ein Continuous Integration mit automatisierten Integrationstest, ein Continous Delivery für das auslieferbare Artefakt und wenn möglich Continuous Deployment. In den ersten Phasen, wird das Deployment noch manuell freigegeben, jedoch automatisch deployt.