Nach dem Deployment: Was Sie prüfen sollten, bevor Sie es als erledigt betrachten

Die Pipeline wird grün. Build-Artefakte werden hochgeladen. Das Deployment-Skript läuft fehlerfrei durch. Viele Teams hören hier auf und gehen davon aus, dass die neue Version live und funktionsfähig ist. Diese Annahme ist gefährlich.

Eine grüne Pipeline bedeutet nur, dass der Auslieferungsprozess ohne technische Fehler durchgelaufen ist. Sie bedeutet nicht, dass die neue Version tatsächlich in Produktion funktioniert. Zwischen einer erfolgreichen Pipeline und einem funktionierenden Deployment klafft eine Lücke, die aktiv überprüft werden muss.

Warum Pipeline-Erfolg nicht ausreicht

Produktionsumgebungen unterscheiden sich von Staging- oder Testumgebungen. In der Produktion trifft Ihre neue Version auf echte Daten, echte Traffic-Muster und echte Netzwerkbedingungen. Es passieren Dinge, die keine Pipeline erkennen kann:

  • Eine Datenbankverbindung, die langsamer wird, weil der Produktionsdatensatz zehnmal größer ist als im Staging
  • Eine Cache-Konfiguration, die mit Testabfragen einwandfrei funktioniert, aber bei tatsächlichen Benutzerzugriffsmustern versagt
  • Ein falsch konfigurierter Server, der vom Deployment-Skript nicht erfasst wurde
  • Eine Drittanbieter-API, die unter echter Last anders reagiert

Die Pipeline führt Skripte aus und prüft Code. Sie weiß nicht, wie sich das System verhält, wenn es auf die Realität trifft. Deshalb brauchen Sie einen separaten Schritt nach dem Deployment: die Verifikation.

Der Unterschied zwischen Deployment und Verifikation

Deployment ist der Vorgang, eine neue Version in eine Umgebung zu bringen. Verifikation ist der Vorgang, der bestätigt, dass die neue Version in dieser Umgebung wie erwartet funktioniert.

Dies sind zwei verschiedene Aktivitäten. Beim Deployment geht es um Maschinen und Skripte. Bei der Verifikation geht es um Verhalten und Signale. Viele Teams behandeln sie als eine Sache oder überspringen die Verifikation ganz, weil die Pipeline gesagt hat, dass alles in Ordnung sei.

Das folgende Flussdiagramm veranschaulicht, wie Deployment und Verifikation separate Pfade sind, die beide erfolgreich sein müssen, bevor ein Deployment als abgeschlossen gilt:

flowchart TD A[Pipeline Grün] --> B[Deployment-Skript läuft] B --> C[Artefakte hochgeladen] C --> D[Deployment-Pfad abgeschlossen] D --> E{Verifikations-Pfad} E --> F[Smoke-Test] F --> G{Bestanden?} G -- Nein --> H[Rollback] G -- Ja --> I[Fehlerrate prüfen] I --> J{Im Rahmen?} J -- Nein --> H J -- Ja --> K[Latenz prüfen] K --> L{Im Rahmen?} L -- Nein --> H L -- Ja --> M[Durchsatz prüfen] M --> N{Erwartetes Volumen?} N -- Nein --> H N -- Ja --> O[Deployment abgeschlossen]

In dem Moment, in dem Sie das Deployment als abgeschlossen betrachten, sobald das Skript fertig ist, gehen Sie eine Wette ein, dass in der Produktion nichts Unerwartetes passiert. Diese Wette mag bei einfachen Änderungen aufgehen. Bei allem, was Datenbankmigrationen, Konfigurationsänderungen oder Infrastruktur-Updates betrifft, stehen die Chancen gegen Sie.

Beginnen Sie mit einem Smoke-Test

Der grundlegendste Verifikationsschritt ist ein Smoke-Test. Der Begriff stammt aus der Hardwaretechnik: Wenn Sie ein neues Gerät zum ersten Mal einschalten, prüfen Sie, ob Rauch austritt. Kein Rauch bedeutet, dass das Gerät zumindest nicht in Flammen aufgegangen ist.

Beim Software-Deployment ist ein Smoke-Test eine schnelle Prüfung, ob die neue Version lebt und antwortet. Er beantwortet eine Frage: Kann diese Version Anfragen annehmen und sinnvolle Antworten zurückgeben?

Ein praktischer Smoke-Test könnte Folgendes umfassen:

Hier ist ein minimales Bash-Skript, das einen Smoke-Test gegen einen bereitgestellten Endpunkt ausführt und bei Fehlschlag mit einem Nicht-Null-Code beendet wird:

#!/bin/bash
# smoke-test.sh - Schnellprüfung, ob die bereitgestellte Version lebt

URL="https://your-app.example.com/health"
EXPECTED_STATUS=200

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_STATUS" -ne "$EXPECTED_STATUS" ]; then
    echo "Smoke-Test fehlgeschlagen: erwarteter Status $EXPECTED_STATUS, erhalten $HTTP_STATUS"
    exit 1
fi

echo "Smoke-Test bestanden: $URL gab $HTTP_STATUS zurück"
exit 0
  • Aufrufen der Hauptseite und Prüfen auf eine 200-Antwort
  • Aufrufen eines einfachen API-Endpunkts und Überprüfen der Antwortstruktur
  • Bestätigen, dass die Datenbankverbindung lebt
  • Prüfen, ob statische Assets korrekt geladen werden

Smoke-Tests müssen nicht tiefgehend sein. Es sind schnelle, oberflächliche Prüfungen, die offensichtliche Fehler aufdecken. Wenn der Smoke-Test fehlschlägt, wissen Sie, dass etwas ernsthaft falsch ist, und müssen weiteren Traffic stoppen oder einen Rollback durchführen. Wenn er bestanden wird, können Sie zu detaillierteren Prüfungen übergehen.

Prüfen Sie die grundlegenden Signale

Sobald der Smoke-Test bestanden ist, betrachten Sie die operativen Signale des Systems. Dies sind die Metriken, die Ihnen sagen, ob die neue Version normal läuft oder Probleme verursacht.

Die benötigten Signale hängen davon ab, was Sie deployed haben, aber einige sind universell:

  • Fehlerrate: Ist der Prozentsatz fehlgeschlagener Anfragen höher als vor dem Deployment?
  • Latenz: Liegen die Antwortzeiten innerhalb akzeptabler Grenzen? Ein plötzlicher Anstieg deutet oft auf ein Problem hin.
  • Ressourcennutzung: Haben sich CPU-, Arbeitsspeicher- oder Festplattennutzung nach dem Deployment signifikant verändert?
  • Traffic-Volumen: Erhält das System die erwartete Anzahl von Anfragen? Ein plötzlicher Abfall könnte bedeuten, dass Benutzer die neue Version nicht erreichen können.

Sie brauchen dafür keine komplexe Analyse. Vergleichen Sie die aktuellen Werte mit dem gleichen Zeitfenster vor dem Deployment. Wenn Sie ein Monitoring-Dashboard haben, dauert dieser Vergleich nur wenige Minuten.

Der Schlüssel ist, diese Prüfung zu einem standardmäßigen Teil Ihres Deployment-Prozesses zu machen – nicht etwas, das Sie tun, wenn Sie daran denken oder wenn jemand ein Problem meldet.

Verifikation ist Teil des Deployments

Hier ist der notwendige Perspektivwechsel: Verifikation ist keine separate Aktivität, die nach dem Deployment stattfindet. Verifikation ist Teil des Deployments selbst. Das Deployment ist erst abgeschlossen, wenn Sie genügend Vertrauen haben, dass die neue Version normal läuft.

Das hat eine praktische Konsequenz für Ihre Pipeline. Die Pipeline sollte das Deployment nicht als erfolgreich markieren, wenn das Skript fertig ist. Sie sollte warten, bis die Verifikation bestanden ist. Wenn die Verifikation fehlschlägt, sollte die Pipeline das Deployment als fehlgeschlagen melden, selbst wenn das Skript fehlerfrei gelaufen ist.

Einige Teams implementieren dies, indem die Pipeline nach dem Deployment pausiert und auf eine manuelle Bestätigung wartet. Andere automatisieren den Smoke-Test und die grundlegenden Signalprüfungen und markieren den Erfolg erst, wenn diese Prüfungen bestanden sind. Beide Ansätze sind besser als die Annahme, dass alles in Ordnung sei.

Unterschiedliche Änderungstypen erfordern unterschiedliche Prüfungen

Nicht alle Deployments sind gleich. Ein Anwendungs-Update, eine Datenbankmigration und eine Infrastrukturänderung haben jeweils unterschiedliche Risiken und unterschiedliche zu prüfende Signale.

Bei einem Anwendungs-Update liegen die Hauptrisiken in der Anfrageverarbeitung, der Korrektheit der Antworten und der Integration mit bestehenden Diensten. Smoke-Tests und Fehlerratenprüfungen sind in der Regel ausreichend.

Bei einer Datenbankmigration sind die Risiken anders. Sie müssen prüfen, ob die Migration korrekt durchgeführt wurde, ob die Datenintegrität erhalten ist und ob die Abfrageleistung nicht nachgelassen hat. Zu den Signalprüfungen sollten die Auslastung des Datenbankverbindungspools, die Abfragelatenz und gegebenenfalls die Replikationsverzögerung gehören.

Bei einer Infrastrukturänderung liegen die Risiken in der Konnektivität, der Ressourcenverfügbarkeit und der Korrektheit der Konfiguration. Zu den Signalprüfungen sollten Netzwerklatenz, Zertifikatsgültigkeit und der Status der Service-Discovery gehören.

Das Prinzip ist dasselbe: Identifizieren Sie, was bei dieser spezifischen Art von Änderung schiefgehen könnte, und prüfen Sie diese Dinge, bevor Sie das Deployment als abgeschlossen betrachten.

Eine praktische Post-Deployment-Checkliste

Wenn Sie etwas Konkretes zum Einstieg suchen, hier ist eine minimale Checkliste, die für die meisten Webanwendungen funktioniert:

  • Smoke-Test bestanden: Hauptseite, kritische API-Endpunkte, Datenbankverbindung
  • Fehlerrate nicht höher als vor dem Deployment
  • Latenz im normalen Bereich
  • CPU- und Arbeitsspeichernutzung stabil
  • Keine ungewöhnlichen Logs oder Fehlermeldungen in den Anwendungslogs
  • Falls eine Datenbankmigration beteiligt war: Migrationsstatus erfolgreich, Abfrageleistung normal

Diese Checkliste ist nicht vollständig, deckt aber die Grundlagen ab. Sie können sie erweitern, sobald Sie lernen, welche Signale für Ihr spezifisches System am wichtigsten sind.

Die wichtigste Erkenntnis

Eine grüne Pipeline bedeutet kein erfolgreiches Deployment. Die Pipeline kümmert sich um die Mechanik der Auslieferung. Die Verifikation kümmert sich um die Realität, ob die neue Version tatsächlich funktioniert. Betrachten Sie das Deployment erst dann als abgeschlossen, wenn Sie überprüft haben, dass die neue Version in der Produktion normal läuft. Diese eine Gewohnheit wird Probleme abfangen, bevor Ihre Benutzer sie bemerken.