Continuous Deployment ist eine Weiterentwicklung von Continuous Delivery. Jede Änderung, die alle automatisierten Build-, Test- und Qualitätsprüfungen erfolgreich durchläuft, wird automatisch in die Produktionsumgebung ausgerollt. Ziel ist es, Durchlaufzeiten zu minimieren, Feedback zu beschleunigen und Risiken durch kleine, häufige Releases zu reduzieren.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Ausführbares Vorgehen: kann angewendet werden und erzeugt ein Ergebnis.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Continuous Deployment automatisiert das Ausrollen geprüfter Softwareänderungen bis in die Produktion – ohne manuellen Freigabeschritt.
Continuous Deployment entstand als strengere Ausprägung von Continuous Integration und Continuous Delivery. Im Umfeld von Thoughtworks wurde Continuous Delivery als Disziplin beschrieben: Software bleibt jederzeit produktionsbereit, weil Build, Tests und die Deployment-Pipeline automatisiert sind. Continuous Deployment geht weiter: Jede Änderung, die alle Prüfungen besteht, wird direkt in Produktion ausgerollt, um Feedback zu beschleunigen und Release-Risiken zu verkleinern.
Stell dir eine Förderstrecke mit einem automatisch öffnenden Endtor vor. Ein Commit löst Build und Tests aus; bestehen die Prüfungen, wandert das Artefakt durch die Pipeline über produktionsnahe Stufen bis live. Zwischen „grün“ und „produktiv“ gibt es kein menschliches Stoppschild. Techniken wie Blue-Green Deployment können den Umschaltmoment absichern, aber die Freigabeentscheidung bleibt in der Automatisierung.
Continuous Deployment setzt voraus, dass Software jederzeit auslieferbar bleibt; der Unterschied liegt im fehlenden manuellen Freigabeschritt.
Build, Tests und Promotionschritte strukturieren den Weg einer Änderung bis zur Auslieferung.
Build-, Test- und Qualitätschecks dienen als objektive Entscheidungssignale für den nächsten Schritt.
Die Software soll so stabil sein, dass jede geprüfte Änderung ohne Sonderhandlung live gehen kann.
Zwei Umgebungen erlauben ein kontrolliertes Umschalten mit geringerer Ausfallzeit.
Der Ansatz lohnt sich, wenn Teams häufig liefern, Feedback schnell aus der Produktion brauchen und kleine Releases das Risiko senken. Er funktioniert am besten mit sehr guter Testautomatisierung, Beobachtbarkeit und klaren Rollback- oder Umschaltstrategien. Wo Compliance, Freigaben oder instabile Tests nicht sauber automatisierbar sind, ist Continuous Delivery mit manuellem Gate oft realistischer.
Wo dieser Baustein im Themenmodell verortet ist.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.