Was passiert nach dem Deploy: Prüfen, ob die neue Version wirklich funktioniert

Der Deploy-Button wurde gedrückt. Die Pipeline zeigt grün. Dein Team atmet erleichtert auf. Aber wenn du denkst, die Arbeit ist getan, wirst du böse überrascht werden.

Ich habe dieses Muster in unzähligen Teams gesehen. Eine neue Version geht live, alle feiern, und dreißig Minuten später kommt das erste Support-Ticket. Das Feature funktioniert im Staging, aber in der Produktion frisst es Speicher. Die API antwortet auf deine Testaufrufe einwandfrei, aber echter Benutzerverkehr deckt eine Race Condition auf, die niemand bemerkt hat.

Release ist nicht die Ziellinie. Es ist der Moment, in dem der eigentliche Test beginnt.

Warum Staging nicht ausreicht

Dein Team hat vor dem Release wahrscheinlich Tests durchgeführt. Unit-Tests waren erfolgreich. Integrationstests waren grün. Die Staging-Umgebung sah gesund aus. Das ist alles gut, aber es reicht nicht.

Staging hat keine echten Benutzer. Es hat kein echtes Datenvolumen. Es hat nicht die unvorhersehbaren Verkehrsmuster, die die Produktion täglich bewältigt. Eine Datenbankabfrage, die im Staging 50 Millisekunden dauert, kann in der Produktion fünf Sekunden brauchen, weil die Produktionstabelle Millionen von Zeilen hat. Ein Feature, das mit Testkonten einwandfrei funktioniert, kann kaputtgehen, wenn es mit Authentifizierungstoken von einem Dutzend verschiedener Identitätsanbieter konfrontiert wird.

Diese Lücke zwischen Staging und Produktion ist der Grund, warum es Post-Release-Checks gibt. Du musst bestätigen, dass die in der Produktion laufende Version tatsächlich so funktioniert, wie du es erwartest – unter realen Bedingungen.

Beginne mit einem Smoke Test

Das Erste, was du nach dem Release tun solltest, ist ein Smoke Test. Der Name stammt aus der Elektronik: Wenn du eine Platine zum ersten Mal einschaltest, prüfst du, ob Rauch austritt. Kein Rauch bedeutet, dass die Platine nicht durchbrennt, und du kannst mit tiefergehenden Tests fortfahren.

In der Software ist ein Smoke Test eine schnelle Überprüfung, ob die neue Version lebt. Du rufst die Hauptseite auf und bestätigst, dass sie lädt. Du rufst einen kritischen API-Endpunkt auf und prüfst, ob er eine Antwort zurückgibt. Du stellst sicher, dass die Datenbankverbindung hergestellt ist. Du vergewisserst dich, dass der Login-Flow nicht sofort abstürzt.

Smoke Tests sind bewusst oberflächlich. Du testest nicht jedes Feature oder jeden Grenzfall. Du beantwortest eine Frage: Hat der Deployment tatsächlich funktioniert, oder ist die Anwendung bereits kaputt?

Hier ist ein einfacher Bash-Befehl, den du direkt nach dem Deployment ausführen kannst, um einen Smoke Test durchzuführen:

curl -f https://prod.example.com/health && echo "Smoke test passed" || echo "Smoke test failed"
flowchart TD A[Release] --> B[Smoke Test] B -->|Bestanden| C[Verifikation] B -->|Fehlgeschlagen| D[Rollback] C -->|Bestanden| E[Health Monitoring] C -->|Fehlgeschlagen| D E -->|Anomalie erkannt| F{Schweregrad?} F -->|Gering| G[Hotfix] F -->|Schwerwiegend| D E -->|Normal| H[Monitoring fortsetzen] G --> E

Ein guter Smoke Test dauert weniger als zwei Minuten. Wenn du ihn automatisiert hast, läuft er in Sekunden. Wenn du ihn manuell durchführst, halte die Checkliste kurz. Maximal fünf bis zehn Prüfungen. Alles, was länger dauert, driftet bereits in den Bereich der Verifikation ab.

Gehe zur Verifikation über

Sobald der Smoke Test bestanden ist, musst du verifizieren, dass sich die neue Version korrekt verhält. Verifikation ist systematischer. Du vergleichst das tatsächliche Verhalten des Systems mit dem, was du erwartet hast.

Hier wird deine bestehende Testsuite wieder nützlich. Führe die kritischen automatisierten Tests gegen die Produktion aus. Nicht die vollständige Regressionssuite, sondern die Teilmenge, die die gerade geänderten Features abdeckt. Wenn du einen neuen Checkout-Flow hinzugefügt hast, verifiziere, dass Bestellungen aufgegeben werden können. Wenn du den Suchalgorithmus geändert hast, verifiziere, dass die Suchergebnisse sinnvoll sind.

Zur Verifikation gehören auch manuelle Prüfungen für Dinge, die schwer zu automatisieren sind. Überprüfe die Logs auf unerwartete Fehler. Sieh dir die Daten an, die nach dem Release verarbeitet wurden. Bestätige, dass das neue Feature über die normale Benutzeroberfläche erreichbar ist.

Der Hauptunterschied zum Smoke Testing ist die Tiefe. Smoke Testing fragt: „Lebt es?“ Verifikation fragt: „Funktioniert es korrekt?“

Beobachte die Health-Signale

Smoke Tests und Verifikation sind aktive Prüfungen. Du sendest Anfragen und beobachtest Antworten. Aber es gibt eine weitere Ebene der Prüfung, die passiv stattfindet: das Monitoring von Health-Signalen.

Health-Signale sind die Metriken, die dir sagen, ob dein System in guter Verfassung ist. CPU-Auslastung, Speicherverbrauch, Anfragenrate, Fehlerrate, Antwortzeit, Auslastung des Datenbankverbindungspools, Queue-Tiefe. Diese Zahlen ändern sich kontinuierlich, während Benutzer mit deinem System interagieren.

Nach einem Release möchtest du diese Signale auf Anomalien beobachten. Ein plötzlicher Anstieg der Fehlerrate ist eine rote Flagge. Ein allmählicher Anstieg der Speichernutzung könnte auf ein Leck hindeuten. Eine stetig steigende Antwortzeit könnte bedeuten, dass der neue Code unter Last langsamer ist.

Der Unterschied zwischen Health-Signalen und aktivem Testen ist wichtig. Aktives Testen sagt dir, was passiert, wenn du gezielt fragst. Health-Signale sagen dir, was auf natürliche Weise passiert, während Benutzer das System nutzen. Beide sind notwendig.

Richte Dashboards ein, die diese Metriken neben der Baseline der vorherigen Version anzeigen. Noch besser: Konfiguriere Alarme, die ausgelöst werden, wenn Metriken Schwellenwerte überschreiten. Du willst ein Problem nicht entdecken, indem du eine Stunde lang auf ein Diagramm starrst. Du willst, dass das System dir sagt, wenn etwas nicht stimmt.

Wie lange solltest du prüfen?

Die Dauer der Post-Release-Prüfung hängt von der Änderung ab.

Für einen kleinen Bugfix oder eine geringfügige Feature-Erweiterung reichen ein paar Minuten Smoke Testing und Beobachtung der Health-Signale. Wenn in den ersten zehn Minuten nichts kaputtgeht, ist die Änderung wahrscheinlich sicher.

Für ein großes Feature, eine Datenbankmigration oder eine Infrastrukturänderung brauchst du länger. Plane, mehrere Stunden lang zu überwachen. Manche Teams behalten ein großes Release einen ganzen Arbeitstag lang im Auge. Der Grund ist, dass bestimmte Probleme Zeit brauchen, um aufzutauchen. Ein Speicherleck zeigt sich vielleicht erst, wenn das System Tausende von Anfragen verarbeitet hat. Eine langsame Abfrage wird möglicherweise erst sichtbar, wenn die Anzahl der gleichzeitigen Benutzer einen bestimmten Schwellenwert erreicht.

Das Wichtigste ist, den Prüfzeitraum vor dem Release zu definieren. Vereinbare, was du prüfst, wie lange und welcher Schwellenwert einen Rollback auslöst. Triff diese Entscheidungen nicht mitten in einem Incident.

Wenn etwas schiefgeht

Wenn deine Post-Release-Checks ein Problem finden, musst du entscheiden, was zu tun ist. Die Entscheidung läuft in der Regel auf zwei Optionen hinaus: Hotfix oder Rollback.

Ein Hotfix ist angebracht, wenn das Problem klein, isoliert und schnell behebbar ist. Ein Tippfehler in einem Konfigurationswert. Eine fehlende Berechtigung für einen neuen Endpunkt. Ein CSS-Fehler, der nur einen Browser betrifft. Du kannst es patchen und erneut deployen, ohne die Benutzer zu stören.

Ein Rollback ist angebracht, wenn das Problem schwerwiegend ist. Datenkorruption. Eine Sicherheitslücke. Ein Feature, das den gesamten Benutzerflow zerstört. Eine Performance-Regression, die das System unbenutzbar macht. In diesen Fällen ist der schnellste Weg, den Dienst wiederherzustellen, die Rückkehr zur vorherigen Version.

Die Entscheidung sollte vor dem Release getroffen werden, nicht während der Krise. Definiere, was als Hotfix-würdiges Problem gilt und was als Rollback-würdiges Problem gilt. Dokumentiere es. Stelle sicher, dass jeder im Team die Kriterien kennt.

Eine praktische Post-Release-Checkliste

Hier ist eine kurze Checkliste, die du an dein Team anpassen kannst. Passe die Punkte basierend auf deiner Anwendung und deiner Risikotoleranz an.

  • Smoke Test: Hauptseite lädt, kritische API antwortet, Datenbank verbunden
  • Automatisierte Verifikation: Führe die Test-Teilmenge aus, die die geänderten Features abdeckt
  • Manuelle Verifikation: Überprüfe Logs, bestätige, dass das neue Feature zugänglich ist
  • Health-Signale: Überprüfe Fehlerrate, Antwortzeit, Ressourcennutzung
  • Alarmkonfiguration: Verifiziere, dass Monitoring-Alarme aktiv sind und Schwellenwerte gesetzt sind
  • Rollback-Kriterien: Bestätige, dass das Team weiß, was einen Rollback auslöst und wer entscheidet

Die eigentliche Erkenntnis

Post-Release-Checks sind nicht optional. Sie sind der Schritt, der Teams, die selbstbewusst ausliefern, von Teams trennt, die ausliefern und beten. Das Ziel ist nicht, alle Produktionsprobleme zu beseitigen – das ist unmöglich. Das Ziel ist, Probleme schnell zu erkennen, bevor sie viele Benutzer betreffen, und einen klaren Plan zu haben, wie man reagiert, wenn man sie findet.

Dein Deployment ist nicht abgeschlossen, wenn die Pipeline grün wird. Es ist abgeschlossen, wenn du bestätigt hast, dass die neue Version korrekt in der Produktion läuft, unter echtem Traffic, und deine Health-Signale normal aussehen. Das ist der Moment, in dem du wirklich sagen kannst, dass das Release erfolgreich war.