Software-Deployment-Prozess: Flussdiagramm vom Build zur Produktion

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Entwicklung, CI/CD-Pipeline, QA, Release Engineer und Betrieb durch die Rollen, die es bei Ihnen wirklich gibt. Viele Teams haben keinen Release Engineer; führen Sie diese Bahn dann mit derjenigen zusammen, die die Produktion verantwortet, statt ein leeres Band stehen zu lassen. Behalten Sie die CI/CD-Pipeline als eigene Bahn, obwohl sie Automatisierung ist — der Sinn des Diagramms ist gerade zu zeigen, welche Schritte eine Maschine ausführt und welche noch ein Mensch.

2. Legen Sie fest, was das Artefakt ist und wo es liegt

   Halten Sie Artefakttyp (Container-Image, Paket, Bundle), Versionsschema, Ableitung der Version aus dem Commit, die verwendete Registry und die Aufbewahrungsdauer fest. Formulieren Sie dann die Regel, auf der der Rest des Diagramms beruht: einmal bauen und dasselbe Artefakt weiterreichen, niemals je Umgebung neu bauen. Baut Ihre Pipeline heute neu, markieren Sie das im Diagramm — es zerreißt die Verbindung zwischen Getestetem und Ausgeliefertem.

3. Definieren Sie, was jedes Gate wirklich prüft

   „Quality Gate bestanden?“ taugt nur so viel wie seine Definition. Legen Sie fest, welche Testsuites grün sein müssen, welche Toleranz für instabile Tests oder Abdeckung Sie akzeptieren, welche Sicherheits- und Abhängigkeitsscans den Build blockieren und wer ein rotes Ergebnis übersteuern darf. Tun Sie dasselbe für Smoke- und Integrationstests auf Staging und listen Sie die bekannten Unterschiede zwischen Staging und Produktion auf (Datenvolumen, Sandboxes Dritter, verkleinerte Infrastruktur), damit klar ist, was ein grüner Staging-Lauf beweist — und was nicht.

4. Legen Sie das Änderungsfenster fest und wer es öffnet

   Halten Sie fest, wann Deployments laufen dürfen, wer sie freigibt und was mit einem nicht freigegebenen Deployment geschieht. Vermerken Sie, ob dieser Deployment-Typ als Standardänderung vorab autorisiert ist oder jedes Mal einzeln freigegeben werden muss, und benennen Sie, wer außerhalb der Regelzeiten freigeben darf. Wenn ein zurückgestelltes Deployment auf das nächste Fenster wartet, legen Sie fest, wie lange das Artefakt gültig bleibt, bevor es neu gebaut und getestet werden muss.

5. Wählen Sie je Service eine Strategie und schreiben Sie die Rollout-Schritte auf

   Entscheiden Sie je Service zwischen Blue-Green und Canary und tragen Sie die Wahl ins Diagramm ein. Beschreiben Sie dann die Mechanik: die Schrittweiten der Verkehrsumlenkung, die Beobachtungsdauer dazwischen, die Health Checks je Stufe und die Vergleichsbasis für die Canary. Behandeln Sie Datenbankänderungen getrennt, denn eine Schemamigration ist meist der Grund, warum ein Rollback nicht bloß ein Zurückschalten ist; Expand- und Contract-Migrationen vom Code-Deployment zu trennen hält die alte Version lauffähig.

6. Machen Sie den Rollback-Auslöser messbar und veröffentlichen Sie das Diagramm

   Ersetzen Sie „jemandem fällt es auf“ durch ein Signal, das die Pipeline selbst auswerten kann: Fehlerrate oder Latenz gegen das Service Level Objective über ein festgelegtes Beobachtungsfenster, mit vereinbarter Konsequenz. Üben Sie den Rollback, damit Sie wissen, wie lange er dauert. Stellen Sie das Diagramm dann neben das Runbook, holen Sie die Freigaben der darin benannten Personen ein, führen Sie genau eine gültige Fassung und überprüfen Sie sie nach jedem Deployment, das schiefgegangen ist.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Deployment-Prozess und Release-Prozess?

Der Release-Prozess entscheidet, was ausgeliefert wird und ob überhaupt: welche Änderungen im Umfang sind, wann der Umfang eingefroren wird, wer die UAT abnimmt und ob die Go/No-Go-Entscheidung Ja lautet. Der Deployment-Prozess ist die Mechanik darunter: ein Artefakt einmal bauen, versionieren, übernehmen, auf Staging prüfen, auf die Produktionsinfrastruktur bringen und bei Auffälligkeiten zurückrollen. Das Verhältnis ist nicht eins zu eins. Ein einzelnes Release kann mehrere Deployments umfassen, und viele Deployments haben gar kein Release — etwa wenn Code hinter einem Feature Flag ausgeliefert und erst später aktiviert wird. Diese Vorlage deckt die Mechanik ab; wenn Sie Scope Freeze, UAT-Abnahme und Go/No-Go brauchen, nutzen Sie die Vorlage für den Software-Release-Prozess.

Aus welchen Phasen besteht ein Software-Deployment-Prozess?

Fünf Phasen decken die meisten Teams ab. Build und Versionierung: Änderung mergen, das Artefakt einmal aus einem sauberen Checkout bauen und mit seinem Commit stempeln. Test und Quality Gate: automatisierte Tests und Scans ausführen und Fehlschläge an die Entwicklung zurückgeben statt nach vorn. Staging: das Artefakt in die Registry übernehmen, auf Staging ausrollen und mit Smoke- und Integrationstests prüfen. Freigabe und Zeitfenster: das Änderungsfenster für die Produktion beantragen und das Deployment freigeben lassen — oder es auf das nächste verschieben. Produktions-Rollout: Blue-Green oder Canary ausrollen, den Datenverkehr schrittweise mit Health Checks umlenken, bei überschrittenem Fehlerbudget automatisch zurückrollen, sonst den Rollout abschließen, überwachen und den Deployment-Datensatz schließen.

Sollten wir Blue-Green oder Canary ausrollen?

Blue-Green betreibt zwei Produktionsumgebungen und schaltet den Datenverkehr zwischen ihnen um; die vorherige Version bleibt warm, das Zurückschalten ist nahezu sofort möglich. Der Preis ist in etwa doppelte Kapazität während des Deployments, und beim Umschalten wechseln alle Nutzenden gleichzeitig — ein Problem, das erst unter echtem Verkehr auftritt, trifft damit sofort jeden. Canary schickt zunächst einen kleinen Anteil echten Verkehrs auf die neue Version und deckt so Probleme auf, die synthetische Prüfungen übersehen; dafür braucht es Verkehrssteuerung und nach Version aufschlüsselbare Metriken, es dauert länger, und es setzt bewusst einen Teil der Nutzenden einer Version aus, der man noch nicht traut. Keines von beiden löst Datenbankänderungen: Beide setzen voraus, dass die vorherige Version noch gegen das aktuelle Schema läuft — deshalb werden Migrationen üblicherweise in getrennt ausgerollte Expand- und Contract-Schritte zerlegt.

Wann sollte ein Deployment automatisch zurückgerollt werden?

Wenn ein Signal, das die Pipeline selbst auswerten kann, einen vereinbarten Schwellenwert überschreitet — nicht, wenn jemand ein Dashboard deutet. In der Praxis heißt das: Fehlerrate, Latenz oder eine benannte Geschäftstransaktion, gemessen gegen das Service Level Objective über ein festgelegtes Beobachtungsfenster, mit automatischem Anhalten oder Zurückrollen, sobald der Verbrauch des Fehlerbudgets die vereinbarte Grenze überschreitet. Zwei Dinge machen das tragfähig. Erstens: Üben Sie den Rollback, damit Sie wissen, dass er funktioniert und wie lange er dauert. Zweitens: Halten Sie das Deployment umkehrbar, indem Sie unumkehrbare Schritte — vor allem Schemamigrationen und einseitige Datenänderungen — vom Code-Deployment trennen, sonst versucht die Automatisierung einen Rollback, den die Daten nicht tragen.

Wo sitzt die Freigabe, wenn wir mehrmals täglich deployen?

Jedes Deployment einzeln freizugeben skaliert nicht, und ein Prozess, den niemand einhalten kann, wird umgangen. Die übliche Antwort lautet: den Weg autorisieren statt den Einzelfall. Definieren Sie diesen Deployment-Typ als vorab genehmigte Standardänderung, mit den Gates, Tests und dem automatischen Rollback der Pipeline als Kontrolle, und behalten Sie die Einzelfreigabe für Änderungen außerhalb dieses Modells vor — etwa Schemamigrationen oder alles, was eine geschützte Umgebung berührt. Genau dort sitzt in diesem Diagramm die Entscheidung „Deployment freigegeben?“, und deshalb ist der Zweig „Zurückgestellt“ gezeichnet. Rahmenwerke wie SOC 2 (Kriterium CC8.1) und das Change-Management-Control der ISO/IEC 27001 verlangen, dass Änderungen an der Produktion autorisiert, getestet und dokumentiert sind; eine menschliche Unterschrift je Deployment verlangen sie nicht. Ein Diagramm ist für sich genommen kein Nachweis — was ein Prüfer sehen will, sind die Deployment-Datensätze, Testergebnisse und Freigaben, die es hervorbringt.