Was zählt als gesundes Deployment für Apps, Datenbanken und Infrastruktur

Wenn ein Deployment abgeschlossen ist, wie wissen Sie, dass es tatsächlich funktioniert hat? Nicht der Pipeline-Status. Nicht der grüne Haken. Nicht die Meldung „Deploy erfolgreich“ in Slack. Die eigentliche Frage lautet: Tut das, was Sie deployed haben, tatsächlich das, was es tun soll?

Die Antwort hängt davon ab, was Sie deployed haben. Eine Anwendung, eine Datenbankänderung und ein Infrastruktur-Update benötigen jeweils unterschiedliche Arten der Verifikation. Für alle drei denselben Health Check zu verwenden, ist, als würde man denselben Test nutzen, um zu prüfen, ob ein Automotor anspringt, ob das Öl sauber ist und ob die Reifen genug Luft haben. Alles wichtig, aber die Prüfmethoden sind unterschiedlich.

Verifikation eines Application-Deployments

Beginnen Sie mit der grundlegendsten Frage: Läuft der Anwendungsprozess und nimmt er Verbindungen an? Das entspricht der Prüfung, ob der Server eingeschaltet ist. Sie können einen einfachen Health-Endpunkt ansprechen und auf eine 200-Antwort prüfen. Wenn Sie diese erhalten, lebt die Anwendung.

Das folgende Flussdiagramm zeigt die unterschiedlichen Verifikationspfade für jeden Deployment-Typ, die jeweils zu einer Entscheidung „Gesund“ oder „Rollback“ führen.

flowchart TD subgraph App[Application] A1[Health Check] --> A2[Smoke Tests] A2 --> A3[Synthetische Transaktionen] A3 --> A4{Alles bestanden?} A4 -->|Ja| A5[Gesund] A4 -->|Nein| A6[Rollback] end subgraph DB[Datenbank] D1[Migrationsprüfung] --> D2[Datenintegritätsprüfung] D2 --> D3[Query-Performance-Prüfung] D3 --> D4{Alles bestanden?} D4 -->|Ja| D5[Gesund] D4 -->|Nein| D6[Rollback] end subgraph Infra[Infrastruktur] I1[Konfigurationsvalidierung] --> I2[Konnektivitätstest] I2 --> I3[Ressourcenlimit-Prüfung] I3 --> I4{Alles bestanden?} I4 -->|Ja| I5[Gesund] I4 -->|Nein| I6[Rollback] end

Aber „lebt“ bedeutet nicht „funktioniert“. Eine Anwendung, die Verbindungen annimmt, kann beim ersten Request scheitern. Vielleicht kann sie ihre Konfigurationsdatei nicht lesen. Vielleicht kann sie keine Verbindung zur Datenbank aufbauen. Vielleicht hat sie eine defekte Cache-Verbindung. Diese Probleme zeigen sich nicht in einem einfachen Health Check.

Deshalb muss die Anwendungsverifikation tiefer gehen. Führen Sie Smoke Tests durch, die mehrere Endpunkte nacheinander aufrufen. Simulieren Sie eine synthetische Transaktion, die das Verhalten eines echten Benutzers abbildet: Einloggen, etwas suchen, ein Formular absenden, ausloggen. Wenn dieser synthetische Ablauf erfolgreich ist, haben Sie stärkere Belege dafür, dass die Anwendung tatsächlich funktioniert – und nicht nur läuft.

Der Schlüssel ist, die Teile zu testen, die für Ihre Benutzer am wichtigsten sind. Wenn die Kernfunktion Ihrer Anwendung die Suche nach Datum ist, sollte Ihre Verifikation eine Suchanfrage mit einem Datumsbereich enthalten. Wenn Benutzer Dateien hochladen, sollte Ihre Verifikation einen Upload-Ablauf enthalten. Testen Sie nicht bei jedem Deployment alles, aber testen Sie die kritischen Pfade.

Hier ist ein praktisches Beispiel für einen Health Check und ein Skript für eine synthetische Transaktion, das Sie nach dem Deployment ausführen könnten:

# Health Check: Prüfen, ob die App lebt
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep -q "200"; then
  echo "Health Check bestanden"
else
  echo "Health Check fehlgeschlagen"
  exit 1
fi

# Smoke Test: Simulieren eines Kern-Benutzerablaufs (Login, Suche, Absenden)
#!/bin/bash
set -euo pipefail

BASE_URL="http://localhost:8080"

# Schritt 1: Login
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","password":"testpass"}')
TOKEN=$(echo "$LOGIN_RESPONSE" | jq -r '.token')

# Schritt 2: Suche
SEARCH_RESPONSE=$(curl -s "$BASE_URL/search?q=test&date_from=2024-01-01" \
  -H "Authorization: Bearer $TOKEN")
if ! echo "$SEARCH_RESPONSE" | jq -e '.results | length > 0' > /dev/null; then
  echo "Suche lieferte keine Ergebnisse"
  exit 1
fi

# Schritt 3: Formular absenden
SUBMIT_RESPONSE=$(curl -s -X POST "$BASE_URL/submit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"test","content":"test content"}')
if ! echo "$SUBMIT_RESPONSE" | jq -e '.id' > /dev/null; then
  echo "Formularabsendung fehlgeschlagen"
  exit 1
fi

echo "Smoke Test bestanden"

Verifikation einer Datenbankänderung

Datenbanken sprechen kein HTTP. Sie können keinen Datenbank-Endpunkt anpingen und eine 200-Antwort erhalten. Die Verifikation von Datenbanken dreht sich um Schemaänderungen, Indexmodifikationen, Stored Procedures und Referenzdaten-Updates. Die Frage ist: Ist die Migration fehlerfrei durchgelaufen und hat sie etwas kaputt gemacht, das vorher funktioniert hat?

Führen Sie das Migrationsskript zunächst in einer Staging-Umgebung aus. Prüfen Sie die Ausgabe auf Fehler. Wenn die Migration erfolgreich war, führen Sie Test-Queries aus, die die normalen Zugriffsmuster der Anwendung repräsentieren. Wenn Sie einen Index geändert haben, prüfen Sie, ob die Queries, die auf diesen Index angewiesen sind, noch akzeptabel schnell laufen. Wenn Sie eine Stored Procedure geändert haben, führen Sie sie mit Testdaten aus und verifizieren Sie die Ergebnisse.

Die Datenbankverifikation muss auch bestätigen, dass ein Rollback möglich ist. Ein Migrationsskript, das nicht rückgängig gemacht werden kann, ist ein Risiko. Testen Sie das Rollback in Ihrer Staging-Umgebung. Stellen Sie sicher, dass es den vorherigen Zustand sauber wiederherstellt, ohne Datenverlust oder Korruption. Wenn Sie nicht sicher rollbacken können, haben Sie die Änderung nicht vollständig verifiziert.

Ein häufiger Fehler ist, die Datenbankverifikation als einmalige Prüfung zu betrachten. Datenbankänderungen können subtile Auswirkungen haben, die erst unter Produktionslast sichtbar werden. Ein neuer Index kann eine Query beschleunigen, aber eine andere verlangsamen. Eine Schemaänderung kann mit Testdaten einwandfrei funktionieren, aber mit echten Datenmengen Locking-Probleme verursachen. Deshalb sollte die Datenbankverifikation sowohl funktionale als auch Performance-Prüfungen umfassen, selbst wenn die Performance-Prüfungen einfache Basislinienvergleiche sind.

Verifikation von Infrastrukturänderungen

Infrastruktur umfasst Server, Load Balancer, Firewalls, DNS-Einträge, TLS-Zertifikate und Netzwerk-Routing. Wenn Sie die Infrastruktur ändern, verändern Sie die Umgebung, von der alles andere abhängt. Eine falsch konfigurierte Firewall kann Datenbankverbindungen lautlos unterbrechen. Eine falsche Load-Balancer-Regel kann Traffic an die falschen Server senden. Ein abgelaufenes TLS-Zertifikat kann Ihre Anwendung über HTTPS unerreichbar machen.

Infrastrukturverifikation dreht sich um Konnektivität und Konfiguration. Prüfen Sie nach dem Ändern einer Firewall-Regel, ob die Anwendung noch die Datenbank erreicht. Prüfen Sie nach dem Aktualisieren eines Load Balancers, ob der Traffic die korrekten Backend-Server erreicht. Prüfen Sie nach der Erneuerung eines TLS-Zertifikats, ob HTTPS-Verbindungen ohne Sicherheitswarnungen funktionieren.

Diese Prüfungen müssen oft von außerhalb der Infrastruktur selbst ausgeführt werden. Sie können die externe Konnektivität nicht von innerhalb des Netzwerks testen. Verwenden Sie Skripte oder Tools, die Verbindungen von außen simulieren. Pingen Sie die Endpunkte an. Prüfen Sie das Ablaufdatum des Zertifikats. Verifizieren Sie, dass die DNS-Auflösung die korrekten IP-Adressen zurückgibt.

Infrastrukturänderungen haben zudem oft Kaskadeneffekte. Das Ändern eines DNS-Eintrags kann mehrere Dienste betreffen. Das Aktualisieren einer Firewall-Regel kann Traffic blockieren, der zuvor erlaubt war. Deshalb sollte die Infrastrukturverifikation eine Konnektivitätskarte enthalten: eine Liste aller Verbindungen, die funktionieren müssen, und einen Test für jede einzelne.

Das gemeinsame Prinzip

Auch wenn sich die Verifikationsmethoden unterscheiden, ist das Prinzip dasselbe: Jedes Deployment muss einen Nachweis hinterlassen, dass das deployed Objekt korrekt funktioniert. Ein Nachweis kann ein Logeintrag über eine erfolgreiche Migration sein, eine HTTP-Antwort, die zeigt, dass die Anwendung Requests bedienen kann, oder ein Ping-Ergebnis, das zeigt, dass ein Server erreichbar ist. Ohne Nachweis wissen Sie nicht, ob das Deployment erfolgreich war. Sie wissen nur, dass die Pipeline durchgelaufen ist.

Eine praktische Verifikations-Checkliste

Verwenden Sie dies als Ausgangspunkt, nicht als endgültige Liste. Passen Sie sie an Ihre spezifischen Systeme an.

  • Anwendung: Health-Endpunkt gibt 200 zurück, synthetische Transaktion für den Kern-Benutzerablauf erfolgreich, kritische externe Abhängigkeiten (Datenbank, Cache, API) sind erreichbar.
  • Datenbank: Migrationsskript läuft fehlerfrei, Test-Queries liefern korrekte Ergebnisse, Query-Performance liegt im akzeptablen Bereich, Rollback-Skript funktioniert in Staging.
  • Infrastruktur: Konnektivität zwischen allen abhängigen Komponenten ist verifiziert, TLS-Zertifikate sind gültig und laufen nicht bald ab, DNS-Auflösung liefert korrekte Einträge, Firewall-Regeln erlauben den erforderlichen Traffic.

Wann ist ein Deployment tatsächlich abgeschlossen?

Ein Deployment ist abgeschlossen, wenn Sie verifiziert haben, dass die Änderung in ihrer Umgebung korrekt funktioniert. Nicht, wenn die Pipeline grün wird. Nicht, wenn das Ticket geschlossen ist. Nicht, wenn der Teamleiter sagt: „Sieht gut aus.“ Das Deployment ist abgeschlossen, wenn Sie einen Nachweis haben, dass die Anwendung, die Datenbank oder die Infrastruktur das tut, was sie tun soll.

Dieser Nachweis ist das, was ein Deployment, das stattgefunden hat, von einem Deployment unterscheidet, das erfolgreich war.