Nach dem Deployment: Promote, Hold, Rollback, Roll-Forward, Pause oder Disable

Das Deployment ist gerade abgeschlossen. Ihre neue Version läuft in Produktion und bedient echten Traffic. Die Pipeline zeigt grün, die Logs fließen, und Ihre Monitoring-Dashboards leuchten mit frischen Daten auf. Was nun?

Dieser Moment zwischen Deployment und Erfolgsmeldung ist der Punkt, an dem die meisten Teams ins Stocken geraten. Manche stürmen voran und erklären die Sache für erledigt. Andere erstarren, unsicher, ob das, was sie sehen, normale Schwankungen oder der Beginn einer Katastrophe sind. Die Realität ist: Ein abgeschlossenes Deployment ist keine Entscheidung – es ist der Beginn einer solchen.

Sobald Observability-Signale eintreffen, haben Sie sechs mögliche Wege. Jeder passt zu einer anderen Situation, und jeder hat andere Konsequenzen. Zu wissen, welchen man wählt und wann, unterscheidet Teams, die Deployments souverän handhaben, von Teams, die einfach nur hoffen, dass alles gut geht.

Promote: Die Version ist gut

Promote bedeutet, dass Sie die neue Version zur offiziellen Produktionsversion erklären. Der gesamte Traffic bleibt auf ihr, und die alte Version kann archiviert oder entfernt werden. Das ist das Ergebnis, das jeder will, aber es sollte niemals überstürzt werden, nur weil die Pipeline bestanden hat.

Sie promoten, wenn alle Observability-Signale innerhalb Ihrer SLO-Grenzen bleiben. Fehlerraten sind normal, die Latenz ist nicht angestiegen, das Error Budget ist noch gesund, und Ihre Smoke-Tests haben in der Produktion bestanden. Die Daten bestätigen, was die Pipeline bereits angedeutet hat: Diese Version ist sicher.

Die Falle hier ist das zu frühe Promoten. Eine grüne Pipeline bedeutet, dass Build und Tests bestanden sind, aber nicht, dass das Verhalten in der Produktion verifiziert ist. Geben Sie der neuen Version genügend Zeit, um aussagekräftige Daten zu sammeln, bevor Sie sie für abgeschlossen erklären. Was nach zwei Minuten stabil aussieht, könnte nach zehn Minuten Probleme offenbaren.

Hold: Noch nicht überzeugt

Hold bedeutet, dass die neue Version weiterläuft, Sie sie aber noch nicht zur offiziellen Version erklären. Sie warten auf weitere Daten. Vielleicht wird der Traffic noch hochgefahren, oder Sie sehen eine kleine Anomalie, die Rauschen sein könnte – oder der Beginn von etwas Schlimmerem.

Hold ist der sichere Mittelweg. Sie geraten nicht in Panik, aber Sie feiern auch nicht. Die Version bedient weiterhin Traffic, während Sie auf Muster achten. Die wichtigste Konsequenz: Sie können das nächste Deployment erst starten, wenn dieses abgeschlossen ist. Hold blockiert die Pipeline – und das ist beabsichtigt. Es zwingt das Team zur Untersuchung, bevor weitere Änderungen auf die Unsicherheit oben drauf gesattelt werden.

Diese Option eignet sich gut, wenn Sie ein Bauchgefühl haben, dass etwas nicht stimmt, aber noch keine harten Beweise. Vertrauen Sie diesem Gefühl. Wenn die Daten nicht eindeutig „Promote“ sagen, erzwingen Sie es nicht.

Rollback: Zurück zu dem, was funktioniert hat

Rollback bedeutet die Rückkehr zur vorherigen stabilen Version. Sie ziehen die neue Version zurück und setzen die alte wieder ein. Das fühlt sich wie ein Fehler an, ist es aber nicht. Es ist ein kontrollierter Rückzug aus einer schlechten Situation.

Sie rollen zurück, wenn die Fehlerraten Ihr SLO überschreiten, das Error Budget schneller als erwartet schrumpft oder ein kritischer Fehler erkannt wurde. Die Kriterien sind klar und objektiv. Wenn die Zahlen sagen, dass die neue Version schlechter ist als die alte, zögern Sie nicht.

Der Haken: Rollback funktioniert nur, wenn Sie sich darauf vorbereitet haben. Der Mechanismus muss vor dem Notfall getestet werden, nicht währenddessen entwickelt. Datenbankänderungen, die nicht abwärtskompatibel sind, können ein Rollback unmöglich machen – weshalb Roll-Forward als Alternative existiert.

Roll-Forward: Vorwärts reparieren statt zurückgehen

Roll-Forward bedeutet, dass Sie die aktuelle Version weiterlaufen lassen, aber sofort eine neue Version bauen, die das Problem behebt. Statt zurückzusetzen, schieben Sie einen Fix oben auf die fehlerhafte Version.

Diese Option ist sinnvoll, wenn das Problem klein ist und Ihr Team schnell einen Fix liefern kann. Sie ist auch die einzige Wahl, wenn ein Rollback nicht möglich ist – zum Beispiel, wenn eine Datenbankmigration das Schema so geändert hat, dass der alte Code nicht mehr damit umgehen kann.

Roll-Forward erfordert Vertrauen, dass der Fix tatsächlich funktioniert. Wenn Sie raten, könnten Sie die Sache verschlimmern. Es setzt das Team außerdem unter Druck, schnell zu liefern, was zu übereilten Entscheidungen führen kann. Setzen Sie Roll-Forward ein, wenn der Weg klar ist, nicht wenn Sie auf das Beste hoffen.

Pause: Anhalten und untersuchen

Pause bedeutet, dass Sie den Deployment-Prozess anhalten, ohne das aktuell Laufende zu ändern. Die neue Version bleibt bestehen, aber es können keine weiteren Deployments durchgeführt werden, bis die Untersuchung abgeschlossen ist.

Nutzen Sie Pause, wenn Sie etwas Seltsames sehen, das aber nicht schwerwiegend genug für ein Rollback ist. Die Latenz steigt in einer Region leicht an. Fehlerraten klettern nach oben, bleiben aber innerhalb des SLO. Ein einzelner Endpunkt zeigt ungewöhnliches Verhalten, während alles andere normal aussieht.

Pause verschafft Ihnen Zeit, um zu verstehen, was passiert, bevor Sie eine größere Entscheidung treffen. Es verhindert, dass das Team ein überstürztes Rollback durchführt, das vielleicht gar nicht nötig ist, oder ein überstürztes Promote, das vielleicht verfrüht wäre. Der Preis ist, dass die Pipeline blockiert ist – aber das ist ein geringer Preis im Vergleich zu einer falschen Entscheidung.

Disable: Den kaputten Teil abschalten

Disable bedeutet, dass Sie eine bestimmte Funktion oder Funktionalität deaktivieren, ohne die gesamte Version zurückzusetzen. Dazu benötigen Sie Feature Flags oder einen anderen Mechanismus, um einzelne Fähigkeiten unabhängig voneinander umzuschalten.

Dies ist der leichteste Eingriff. Wenn nur eine Funktion Probleme bereitet – ein neuer Suchalgorithmus, ein neu gestalteter Checkout-Ablauf, ein geänderter API-Endpunkt – können Sie diese Funktion abschalten, während alles andere weiterläuft. Die Benutzer verlieren den Zugriff auf diese eine Funktion, aber der Rest der Anwendung läuft normal weiter.

Disable ist schneller und sicherer als ein Rollback, wenn das Problem isoliert ist. Es gibt dem Team auch Zeit, die spezifische Funktion zu reparieren, ohne das gesamte Deployment zu stören. Voraussetzung ist, dass Ihre Architektur granulare Toggles unterstützt – das ist eine Investition wert, wenn Sie häufig deployen.

Wie man sich entscheidet

Die richtige Entscheidung hängt von drei Dingen ab: wie schlimm das Problem ist, wie viel Error Budget Ihnen noch bleibt und wie schnell Ihr Team reagieren kann. Teams, die SLOs definiert und das Error Budget im Auge haben, haben eine objektive Grundlage für diese Entscheidungen. Wenn das Error Budget fast aufgebraucht ist, kann selbst eine kleine Anomalie ein Rollback rechtfertigen. Wenn das Error Budget reichlich vorhanden ist, können Sie sich für Hold oder Pause entscheiden, um weiter zu untersuchen.

Der folgende Entscheidungsbaum führt Ihre Observability-Signale zur passenden Aktion:

flowchart TD A[Deployment finished, monitoring data available?] -->|Yes| B{All signals within SLO?} A -->|No| C[Wait for data, then re-evaluate] B -->|Yes| D{Error budget nearly exhausted?} B -->|No| E{Problem isolated to one feature?} D -->|No| F[Promote] D -->|Yes| G{Hold or Rollback?} G -->|Hold| H[Hold] G -->|Rollback| I[Rollback] E -->|Yes| J[Disable] E -->|No| K{Can rollback safely?} K -->|Yes| I K -->|No| L{Roll-forward fix ready?} L -->|Yes| M[Roll-Forward] L -->|No| N[Pause]

Vermeiden Sie es, diese Entscheidungen nur aus dem Bauch heraus zu treffen. Wenn die Daten klar sind, ist der Weg klar. Wenn die Daten unklar sind, halten Sie inne oder pausieren Sie, bis sie klar werden.

Praktische Checkliste für Deployment-Entscheidungen

  • Haben Sie lange genug gewartet, bis aussagekräftige Observability-Daten vorliegen?
  • Liegen alle Signale innerhalb der SLO-Grenzen, oder gibt es eine Anomalie, die untersucht werden muss?
  • Haben Sie einen getesteten Rollback-Mechanismus bereit, oder sind Sie durch Datenbankänderungen blockiert?
  • Ist das Problem auf eine einzelne Funktion isoliert, die unabhängig deaktiviert werden kann?
  • Hat Ihr Team die Kapazität, schnell einen Fix zu bauen, wenn Sie sich für Roll-Forward entscheiden?
  • Ist die Pipeline durch Hold oder Pause blockiert, und weiß jeder, warum?

Das Fazit

Ein Deployment ist nicht abgeschlossen, wenn der Code läuft. Es ist abgeschlossen, wenn Sie genügend Daten haben, um eine fundierte Entscheidung über das weitere Vorgehen zu treffen. Die sechs Optionen – Promote, Hold, Rollback, Roll-Forward, Pause und Disable – geben Ihnen ein Vokabular für diese Entscheidung. Nutzen Sie sie bewusst, basierend auf Signalen, nicht auf Vermutungen. Die Version, die Sie deployen, ist nicht die endgültige Antwort. Die Entscheidung, die Sie treffen, nachdem Sie sie beobachtet haben, ist es.