Wann ist ein Deployment wirklich abgeschlossen?

Du hast gerade deinen Deployment-Befehl ausgeführt. Das Terminal zeigt eine saubere, grüne Ausgabe. Keine Fehler. Keine Warnungen. Der neue Container läuft. Die Dateien sind an Ort und Stelle. Dein Team packt zusammen, um nach Hause zu gehen.

Aber ist das Deployment tatsächlich abgeschlossen?

Die meisten Teams behandeln den Moment, in dem der Deploy-Befehl endet, als Ziellinie. Das ist eine gefährliche Annahme. Was du zu diesem Zeitpunkt weißt, ist nur, dass der Prozess des Verschiebens von Dateien oder Neustartens von Diensten erfolgreich abgeschlossen wurde. Du weißt noch nicht, ob die Anwendung tatsächlich funktioniert.

Der Unterschied zwischen Deployen und Gesundsein

Ein Deployment hat zwei unterschiedliche Phasen. Die erste ist der technische Akt, die neue Version zu installieren. Die zweite ist die Überprüfung, ob sich die neue Version korrekt verhält. Viele Teams hören nach Phase eins auf und geben sich damit zufrieden.

Das folgende Flussdiagramm veranschaulicht den oben beschriebenen Zweiphasenprozess:

flowchart TD A[Deploy-Phase] --> B[Dateien verschieben / Dienste neustarten] B --> C[Deploy erfolgreich] C --> D[Verifikationsphase] D --> E[Smoke-Tests] E --> F[Synthetische Transaktionen] F --> G[Signale überwachen] G --> H[Fehlerrate, Latenz, Ressourcen] H --> I[Evidenz gesammelt] I --> J[Deployment abgeschlossen] C -.->|Nicht fertig| K[Deployment NICHT abgeschlossen] style J fill:#a3d9a5 style K fill:#f4a3a3

Denk daran, was nach einem erfolgreichen Deployment schiefgehen kann:

  • Der neue Code hat einen Konfigurationsfehler, der sich erst unter echtem Traffic zeigt
  • Eine Datenbankmigration war erfolgreich, aber der Anwendungscode erwartet einen anderen Spaltennamen
  • Eine Abhängigkeit wurde aktualisiert und hat eine Integration zerstört, die Unit-Tests nicht erfasst haben
  • Die neue Version verbraucht mehr Speicher und löst nach einigen Minuten den OOM-Killer aus

Nichts davon würde in deinen Deployment-Logs auftauchen. Das Terminal würde immer noch "Deploy erfolgreich" anzeigen. Aber die Anwendung wäre kaputt.

Was zählt als Evidenz

Ein Deployment ist erst dann abgeschlossen, wenn du Evidenz hast, dass die neue Version gesund und bereit ist, Benutzer zu bedienen. Diese Evidenz muss messbar und überprüfbar sein. Bauchgefühl und "sieht gut aus für mich" zählen nicht.

Die Evidenz stammt aus mehreren Quellen. Smoke-Tests sind die grundlegendste Ebene. Sie überprüfen, ob die Anwendung startet, die Hauptseite lädt und Kernfunktionen reagieren. Ein fehlgeschlagener Smoke-Test bedeutet, dass etwas Fundamentales nicht stimmt.

Hier ist ein minimales Skript, das die erste Ebene der Evidenzsammelung nach einem Deployment automatisiert:

#!/bin/bash
# post-deploy-verify.sh - Wird nach dem Deploy-Befehl ausgeführt

set -euo pipefail

URL="https://your-app.example.com"
DB_CONN_STRING="postgresql://user:pass@db-host:5432/app"

# 1. Health-Check
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: Health-Check gab $HTTP_CODE zurueck"
  exit 1
fi
echo "PASS: Health-Check gab 200 zurueck"

# 2. Smoke-Test - Hauptseite laedt
if ! curl -s "$URL" | grep -q "<title>App</title>"; then
  echo "FAIL: Hauptseite hat nicht den erwarteten Titel"
  exit 1
fi
echo "PASS: Hauptseite laedt korrekt"

# 3. Datenbank-Konnektivitaetstest
if ! psql "$DB_CONN_STRING" -c "SELECT 1" > /dev/null 2>&1; then
  echo "FAIL: Datenbankverbindung fehlgeschlagen"
  exit 1
fi
echo "PASS: Datenbankverbindung erfolgreich"

echo "Alle Checks bestanden - Deployment-Evidenz gesammelt"

Synthetische Transaktionen gehen tiefer. Sie simulieren echte Benutzerabläufe: Einloggen, nach Daten suchen, ein Formular absenden, eine Bestellung abschließen. Wenn eine synthetische Transaktion erfolgreich ist, weißt du, dass eine vollständige Benutzerreise Ende-zu-Ende funktioniert.

Dann gibt es die Systemsignale, die wir bereits früher in dieser Serie besprochen haben. Nach dem Deployment musst du überprüfen, ob die Verfügbarkeit stabil bleibt, die Fehlerraten nicht ansteigen und die Latenz nicht nachlässt. Wenn all diese Signale normal aussehen, hast du einen starken Hinweis darauf, dass die neue Version keine Probleme verursacht.

Die Falle der beiläufigen Verifikation

Die eigentliche Gefahr ist nicht, dass Teams die Verifikation ganz überspringen. Es ist, dass sie es beiläufig tun. Ein Entwickler wirft einen Blick auf ein Dashboard, sieht grüne Balken und geht davon aus, dass alles in Ordnung ist. Aber dieser Blick könnte einen subtilen Anstieg von 500-Fehlern übersehen. Es könnte übersehen, dass der Checkout-Prozess für eine Teilmenge der Benutzer ausfällt.

Beiläufige Verifikation schlägt fehl, weil sie sich auf menschliche Aufmerksamkeit und Erinnerung verlässt. Der Entwickler, der deployed hat, könnte nach einem langen Tag müde sein. Er könnte es eilig haben, an einem anderen Meeting teilzunehmen. Er könnte nicht genau wissen, welche Signale für diese spezielle Änderung zu überprüfen sind.

Die Lösung besteht darin, deine Evidenzkriterien vor dem Deployment zu definieren. Entscheide im Voraus, welche Signale beweisen, dass das Deployment abgeschlossen ist. Schreibe sie auf. Mache sie explizit.

Ein vernünftiger Satz von Kriterien könnte so aussehen:

  • Smoke-Test für die Hauptseite und den Login-Ablauf bestanden
  • Synthetische Transaktionen für die drei kritischsten Benutzerreisen bestanden
  • Fehlerrate bleibt unter 0,1 Prozent
  • P95-Latenz steigt nicht um mehr als 5 Prozent gegenüber dem Basiswert vor dem Deployment
  • Auslastung des Datenbankverbindungspools bleibt unter 70 Prozent

Wenn all diese Bedingungen erfüllt sind, ist das Deployment abgeschlossen. Wenn eine Bedingung fehlschlägt, ist das Deployment nicht abgeschlossen, selbst wenn der Deploy-Befehl erfolgreich war.

Wer entscheidet, dass das Deployment abgeschlossen ist

In einem kleinen Team trifft oft der Entwickler, der deployed hat, die Entscheidung. Er überprüft die Kriterien, verifiziert die Signale und entscheidet, ob er es als erledigt betrachtet. Das funktioniert, wenn das Team klein ist und jeder das System gut kennt.

Wenn das Team wächst, sollte die Entscheidung auf Automatisierung übergehen. Die Pipeline selbst sollte das Deployment erst dann als abgeschlossen markieren, wenn alle automatisierten Checks bestanden sind. Dies entfernt menschliches Urteilsvermögen aus dem Prozess und gewährleistet Konsistenz. Jedes Deployment erhält die gleiche Verifikation, jedes Mal.

Bei risikoreichen Änderungen möchtest du vielleicht trotzdem einen Menschen im Prozess haben. Ein Senior Engineer oder eine Bereitschaftsperson kann die Evidenz überprüfen und die endgültige Entscheidung treffen. Aber auch dann sollten die Kriterien klar sein. Der Mensch rät nicht, ob die Dinge in Ordnung aussehen. Er überprüft eine vordefinierte Liste von Bedingungen.

Es gibt keine universelle Regel dafür, wie viel Evidenz ausreicht. Ein kleiner Bugfix für ein internes Tool benötigt weniger Verifikation als eine große Funktionsänderung an einem kundenorientierten Zahlungssystem. Wichtig ist, dass sich dein Team auf die Kriterien für jede Art von Änderung einigt.

Eine praktische Checkliste für den Deployment-Abschluss

Hier ist eine einfache Checkliste, die du für dein Team anpassen kannst:

  • Deployment-Befehl fehlerfrei abgeschlossen
  • Smoke-Tests bestanden (Hauptseite, Login, Kernfunktionen)
  • Synthetische Transaktionen bestanden (kritische Benutzerreisen)
  • Fehlerrate innerhalb des akzeptablen Bereichs
  • Latenz innerhalb des akzeptablen Bereichs
  • Ressourcennutzung (CPU, Speicher, Verbindungen) stabil
  • Keine Alarme von Überwachungssystemen ausgelöst
  • Datenbankmigrationen angewendet und verifiziert

Wenn ein Punkt fehlschlägt, ist das Deployment nicht abgeschlossen. Untersuche die Ursache, bevor du den Erfolg erklärst.

Was sich ändert, wenn du das richtig machst

Wenn dein Team zustimmt, dass ein Deployment erst dann abgeschlossen ist, wenn es Evidenz für die Gesundheit gibt, verschiebt sich der gesamte Deployment-Prozess. Deployment ist nicht länger eine technische Aufgabe, die am Terminal endet. Es wird zu einem Übergang, der endet, wenn Benutzer die neue Version sicher nutzen können.

Diese Verschiebung ändert das Verhalten. Teams beginnen, bessere Smoke-Tests zu schreiben, weil sie wissen, dass diese Tests bestimmen, ob sie Feierabend machen können. Sie beginnen, klare Kriterien vor dem Deployment zu definieren, nicht danach. Sie hören auf, das Deployment zu überstürzen, und beginnen, darauf zu achten, was passiert, nachdem die neue Version live gegangen ist.

Wenn dein Team das nächste Mal ein Deployment durchführt, beobachte, was passiert, nachdem der Befehl beendet ist. Entspannt sich jeder und macht weiter? Oder überprüfen sie zuerst die Evidenz? Dieser Moment zeigt dir, ob dein Team wirklich versteht, wann ein Deployment abgeschlossen ist.