Deployment bezeichnet den Prozess der Überführung einer neuen oder aktualisierten Version eines Workflows, Bots, einer Anwendung oder Konfiguration aus der Entwicklungs- oder Testumgebung in eine produktive Betriebsumgebung, in der sie mit echten Daten, für echte Nutzer und mit echten Konsequenzen läuft. Das Deployment ist der finale Schritt in der Prozesskette Sandbox → Testumgebung → Produktion.
Im Kontext der Automatisierung ist Deployment der Moment, in dem eine entwickelte und getestete Automatisierungslösung erstmals oder erneut in der produktiven Umgebung aktiv wird – und ihren Wert für das Unternehmen zu erzeugen beginnt. Ein fehlerhaftes Deployment kann unmittelbare Betriebsunterbrechungen oder Datenfehler verursachen; ein gut geplantes Deployment ist ein kontrollierter, dokumentierter Übergang.
Der Deployment-Prozess
Freigabe
Alle Tests bestanden, Abnahme erteilt
Planung
Zeitfenster, Rollback-Plan, Kommunikation
Ausführung
Neue Version wird in Prod aktiviert
Validierung
Erste Produktionsdaten prüfen, Monitoring aktiv
Freigabe
Rollback-Bereitschaft aufgehoben, stabil
Deployment-Strategien
- Big Bang Deployment: Die gesamte neue Version wird auf einmal in Produktion gebracht. Einfach, aber risikoreich – alle Nutzer sind gleichzeitig betroffen
- Rolling Deployment: Die neue Version wird schrittweise auf einen Teil der Infrastruktur ausgerollt, während der Rest noch die alte Version betreibt – Fehler sind begrenzt
- Blue-Green Deployment: Zwei identische Produktionsumgebungen (Blau = alt, Grün = neu) laufen parallel. Traffic wird von Blau auf Grün umgeschaltet – Rollback ist ein einfaches Zurückschalten
- Canary Deployment: Die neue Version wird zunächst nur für einen kleinen Prozentsatz der Nutzer oder Vorgänge aktiviert. Bei stabilem Betrieb wird der Anteil schrittweise erhöht
Was ein Deployment-Plan enthalten muss
- Zeitfenster: Wann wird deployed – ideale Zeitpunkte sind Zeiten mit geringem Volumen (nachts, Wochenenden)
- Verantwortliche: Wer führt das Deployment durch, wer ist erreichbar für Fragen und Entscheidungen
- Rollback-Kriterien: Unter welchen messbaren Bedingungen wird sofort zurückgesetzt
- Kommunikation: Welche Teams, Kunden oder Nutzer werden vorab über geplante Änderungen oder Wartungsfenster informiert
- Validierungsschritte: Welche erste Prüfung bestätigt, dass das Deployment erfolgreich war
Praxisbeispiel
Ein Automatisierungsdienstleister deployed eine neue Version des Rechnungsworkflows seines Kunden. Deployment-Plan: Samstag 22:00 Uhr, da das Volumen dann am niedrigsten ist. Eine Stunde vor Deployment werden alle laufenden Vorgänge abgeschlossen, die Queue geleert. Um 22:00 Uhr wird die neue Version aktiviert. Automatischer Health-Check: Werden die ersten 10 Rechnungen korrekt verarbeitet? Ja. Um 22:45 Uhr meldet das Monitoring stabile Kennzahlen. Rollback-Bereitschaft wird um 23:30 Uhr aufgehoben. Montag 08:00 Uhr: 847 Rechnungen über das Wochenende fehlerfrei verarbeitet. Das Deployment war ein Erfolg – nicht durch Glück, sondern durch Planung.
