Deploy
Vom Qualitätsnachweis zum kontrollierten Produktionsbetrieb
Die Deploy-Phase bringt die getestete Lösung risikoarm in Produktion: deklarative Infrastruktur, GitOps-basierte Auslieferung und progressive Rollout-Strategien (Canary, Blue-Green) mit automatischen Rollbacks. Legacy-Ablösungen folgen einem gestuften Cutover-Plan mit Parallel-Run.
Einordnung der Phase im TRANSFORM-Vorgehensmodell
Vorgehensmodell
Ergebnis ist die produktive Ziellösung mit nachgewiesener Betriebsfähigkeit: automatisierte Release-Strecke, funktionierende Rollback-Pfade, vollzogener Cutover und ein an den Betrieb übergebenes, dokumentiertes System.
Release- & Cutover-Planung
Festlegung von Rollout-Strategie, Cutover-Fenstern, Datenmigrationsschritten und Abbruchkriterien je Anwendung; Abstimmung mit Fachbereich, Betrieb und Change-Management.
Infrastruktur & Umgebungen (IaC)
Deklarative Bereitstellung aller Umgebungen als Infrastructure as Code; Umgebungsparität von Test bis Produktion, Secrets- und Zertifikatsmanagement.
Progressive Auslieferung
GitOps-basierte Deployments mit Canary- bzw. Blue-Green-Strategie; automatisierte Health-Checks und metrikbasierte Promotion oder Rollback.
Datenmigration & Parallel-Run
Gestufte Datenmigration mit Reconciliation; Parallel-Run von Alt- und Neusystem bis zum Äquivalenznachweis im Produktionsmaßstab.
Cutover & Betriebsübergabe
Kontrollierter Cutover mit Hypercare-Phase; Übergabe von Runbooks, Dashboards und Eskalationspfaden an die Operate-Phase.
Methodik-Mix
Risikoarme Inbetriebnahme über progressive Delivery
| Methode | Einsatzzweck im TRANSFORM-Kontext | Referenz |
|---|---|---|
| Continuous Deployment & Deployment Pipeline | Vollautomatisierte Release-Strecke mit stufenweisen Qualitäts-Gates; Grundlage kurzer, risikoarmer Releasezyklen. | Humble & Farley (2010) |
| GitOps | Deklarativer Soll-Zustand im Versionskontrollsystem mit automatischer Reconciliation; auditierbare, reproduzierbare Deployments. | OpenGitOps / CNCF |
| Progressive Delivery (Canary, Blue-Green) | Schrittweise Verkehrsumschaltung mit metrikbasierter Promotion; begrenzt den Schadensradius von Fehlern. | Google SRE |
| Infrastructure as Code | Versionierte, testbare Infrastrukturdefinitionen; eliminiert Konfigurationsdrift zwischen Umgebungen. | Morris (2020) |
| Strangler-Fig-Migration | Inkrementelle Ablösung von Altsystemen hinter einer Fassade; vermeidet Big-Bang-Cutover. | Fowler (2004) |
| DORA Change Management | Empirisch validierte Praktiken für risikoarme Änderungen; Messung über Change Failure Rate und MTTR. | DORA / Forsgren et al. |
Plattform-Unterstützung
ReqPOOL Suite: Signoff (KI-gestützte Abnahme) · REAM (Enterprise-Architektur)
Signoff — User Acceptance & Sign-Off
Geführte Playbooks für Fachanwender mit multimodaler Auswertung der Bildschirmaufnahmen; ein unabhängiges KI-Prüfmodell bewertet jeden Testfall — die finale Abnahme bleibt beim Kunden.
Signoff — Abnahmebericht als Go/No-Go-Grundlage
Der revisionssichere Abnahmebericht mit vollständiger Traceability von der Spezifikationsklausel bis zum Testergebnis ist die dokumentierte Grundlage der Go-live-Entscheidung — belastbar auch gegenüber Lieferanten und Revision.
REAM — Cut-over-Steuerung
Cut-over-Plan, Datenmigration und Schnittstellenumstellung; der Parallelbetrieb wird gegen die IST-Baseline abgeglichen.
REAM — kontrollierte Legacy-Abschaltung
Abschaltung der Altsysteme zum Stichtag; das Landschaftsinventar wird mit dem Go-live aktualisiert.
Best Practices der Plattformnutzung
- Cutover erst starten, wenn der Signoff-Abnahmebericht ohne offene kritische Findings vorliegt (Gate: Abnahme erteilt).
- Abbruchkriterien und Rollback-Pfade vor jedem Rollout definieren und technisch erproben — ein ungetesteter Rollback ist keiner.
- Den Parallelbetrieb gegen die IST-Baseline aus der Analyse-Phase abgleichen; ungeklärte Abweichungen blockieren die Legacy-Abschaltung.
- Go/No-Go-Entscheidungen ausschließlich im Cutover-Protokoll dokumentieren — mündliche Freigaben sind unzulässig.
- Hypercare-Zeitraum und -Besetzung vor dem Cutover vereinbaren; Übergabe an den Regelbetrieb nur mit abgenommenen Runbooks.
- Nach dem Go-live die Ziel-Landschaft in REAM aktualisieren und die Abschaltung der Altsysteme zum Stichtag nachhalten.
Artefakte & Ergebnisse
- Automatisierte Release-Strecke mit progressiven Rollouts
- Infrastruktur als Code für alle Umgebungen
- Vollzogene Datenmigration mit Reconciliation-Nachweis
- Cutover-Protokoll mit Go/No-Go-Entscheidungen
- Betriebsübergabe-Paket (Runbooks, Dashboards, Eskalationspfade)
Quality Gate — Deploy
Der Übergang in die Folgephase erfolgt über ein formales Quality Gate (Go/No-Go). Die Gate-Kriterien werden im Gate-Review dokumentiert und vom Engagement Lead freigegeben.
- Produktivbetrieb stabil über den vereinbarten Hypercare-Zeitraum
- Rollback-Fähigkeit nachgewiesen
- Datenabgleich ohne offene kritische Abweichungen
- Betriebsübergabe vom Operate-Team bestätigt
Wissenschaftliche Vertiefung
Standardwerk für Deployment-Pipelines und Releasemanagement.
Praxisleitfaden für metrikbasierte progressive Rollouts.
Muster der inkrementellen Legacy-Ablösung.
Umfassende Referenz der DevOps-Prinzipien und Flow-Optimierung.
Forschungsbasierte Fähigkeiten für Delivery-Performance.
Best-Practice-Anleitung: Phase Deploy
Kompakte Checkliste mit Vorgehensmodell, Methodik-Mix und Plattform-Best-Practices für den Einsatz im Engagement.
Best-Practice-Anleitung als PDF laden