Was Ihre Pipeline vor dem Deployment prüfen sollte

Stellen Sie sich vor: Sie pushen eine Änderung, die Pipeline wird grün, und Sie deployen. Zehn Minuten später melden Nutzer Fehler. Die Datenbankmigration hat eine Query zerstört. Eine Abhängigkeit hat eine bekannte Sicherheitslücke eingeschleust. Eine Konfigurationsdatei hatte ein Pflichtfeld nicht gesetzt.

Die Pipeline sagte, alles sei in Ordnung. War es aber nicht.

Das passiert, wenn eine Pipeline nur prüft, ob Code kompiliert und Tests durchlaufen. Das ist notwendig, aber nicht ausreichend. Eine nützliche Pipeline fungiert als Gatekeeper: Sie stoppt Änderungen, die in der Produktion Probleme verursachen würden, bevor sie dort ankommen. Die Frage ist: Was sollte sie prüfen?

Build muss zuerst erfolgreich sein

Das grundlegendste Gate ist, ob der Code überhaupt baut. Wenn ein Entwickler Änderungen pusht, versucht die Pipeline, den Code zu kompilieren oder ein ausführbares Artefakt zu erzeugen. Schlägt der Build fehl – Syntaxfehler, inkompatible Abhängigkeit, kaputte Konfiguration –, gibt es keinen Grund weiterzumachen. Der Code kann gar nicht laufen.

Dieses Gate sollte immer der erste Schritt sein. Es ist schnell, es ist billig, und es filtert Änderungen heraus, die noch nicht einmal testbereit sind. Wenn der Build fehlschlägt, stoppt die Pipeline. Der Entwickler bekommt sofortiges Feedback und kann das Problem beheben, bevor jemand anderes betroffen ist.

Unit-Tests prüfen Verhalten, nicht Implementierung

Sobald der Build erfolgreich ist, kommt das nächste Gate: Unit-Tests. Aber nicht alle Unit-Tests sind gleich gut. Ein guter Unit-Test prüft ein sinnvolles Verhalten von einem relevanten Einstiegspunkt aus. Für einen Backend-Dienst könnte das ein API-Endpunkt oder ein Use Case sein, der durch die echten internen Schichten läuft. Für eine Frontend-App könnte es eine Benutzerinteraktion wie das Klicken eines Buttons oder das Absenden eines Formulars sein.

Der entscheidende Punkt ist: Unit-Tests sollten nicht brechen, wenn Sie internen Code refaktorieren. Sie sollten nur brechen, wenn sich das beobachtbare Verhalten ändert. Wenn ein Unit-Test fehlschlägt, bedeutet das, dass das System nicht mehr korrekt auf eine gültige Eingabe reagiert. Das ist es wert, die Pipeline zu stoppen.

Manche Teams schreiben Unit-Tests, die eng an die Implementierung gekoppelt sind: Sie testen private Methoden, testen jede Klasse einzeln, mocken interne Schichten und brechen bei jeder Refaktorierung. Diese Tests erzeugen Rauschen und verlangsamen die Auslieferung. Mocken Sie die externen Nachbarn, wenn nötig, aber lassen Sie das interne Verhalten den Pfad durchlaufen, den die Anwendung tatsächlich nutzt. Das Gate ist nur nützlich, wenn die Tests zuverlässig sind. Wenn Ihre Unit-Tests häufig aus nicht-funktionalen Gründen fehlschlagen, werden Entwickler sie ignorieren, und das Gate verliert seinen Wert.

Integrationstests erkennen Verbindungsprobleme

Unit-Tests können ohne externe Abhängigkeiten laufen. Integrationstests nicht. Sie prüfen, ob Ihr System tatsächlich mit der Außenwelt kommunizieren kann: einer echten Datenbank, einer Message Queue, einer Drittanbieter-API.

Zum Beispiel: Ihr Unit-Test mockt die Datenbank und läuft durch. Aber die echte Datenbank könnte eine Query wegen eines Schema-Konflikts, eines fehlenden Index oder eines Typkonvertierungsfehlers ablehnen. Integrationstests fangen solche Probleme ab.

Diese Tests benötigen eine vollständigere Umgebung – eine Testdatenbank, Container oder laufende Dienste. Sie sind langsamer als Unit-Tests, aber sie fangen eine andere Klasse von Problemen. Wenn ein Integrationstest fehlschlägt, bedeutet das in der Regel, dass die Änderung nicht mit der tatsächlichen Infrastruktur funktioniert, auf der sie laufen wird.

Security Scans sollten automatisch laufen

Sicherheit ist nichts, was man einer manuellen Überprüfung vor dem Release überlassen kann. Bis jemand den Code ansieht, könnte eine verwundbare Abhängigkeit bereits in der Produktion sein. Automatisierte Security Scans können ohne menschliches Eingreifen laufen und mehrere Dinge prüfen:

• Gibt es Abhängigkeiten mit bekannten Sicherheitslücken?
• Enthält der Code versehentlich Credentials oder API-Keys?
• Gibt es Muster, die ausgenutzt werden könnten, wie SQL-Injection oder unsichere Deserialisierung?

Manche Teams führen statische Analysen des Quellcodes durch. Andere führen dynamische Scans gegen eine laufende Anwendung aus. Beide Ansätze finden unterschiedliche Probleme. Wichtig ist, dass die Pipeline die Sicherheit automatisch prüft, jedes Mal.

Wenn ein Security Scan fehlschlägt, stoppt die Pipeline. Der Entwickler bekommt einen Bericht, der genau zeigt, was falsch ist. Keine manuelle Freigabe nötig, kein Warten auf ein Security-Team, das den Code prüft. Das Gate selbst blockiert die Änderung.

Policy Compliance sorgt für Konsistenz

Nicht jede Prüfung muss technisch sein. Manche betreffen Prozess und Konsistenz. Policy-Compliance-Gates prüfen, ob die Änderung den Regeln folgt, auf die sich Ihr Team oder Ihre Organisation geeinigt hat.

Typische Policy-Prüfungen sind:

• Hat der Code ein Code-Review durchlaufen?
• Folgt der Branch-Name der Konvention (z. B. feature/ oder fix/)?
• Ist der Pull Request zu groß? Manche Teams begrenzen Änderungen auf eine bestimmte Anzahl von Zeilen oder Dateien.
• Stammen alle Abhängigkeiten aus einer genehmigten Registry?

Diese Prüfungen sind administrativ, aber sie sind wichtig. Sie verhindern Situationen, in denen jemand eine 2000-Zeilen-Änderung ohne Review merged oder eine Abhängigkeit aus einer nicht vertrauenswürdigen Quelle eingebunden wird. Die Pipeline setzt die Regeln automatisch durch, sodass sich niemand daran erinnern muss.

Wenn Automatisierung nicht ausreicht

Die fünf oben genannten Gates – Build, Unit-Test, Integrationstest, Security Scan, Policy Compliance – können alle automatisch laufen. Die Pipeline entscheidet über Bestehen oder Nichtbestehen und stoppt, wenn etwas falsch ist. Kein Mensch muss eine Entscheidung treffen.

Aber nicht jede Prüfung sollte automatisiert werden. Manche Entscheidungen erfordern menschliches Urteilsvermögen. Zum Beispiel könnte eine Änderung, die einen kritischen Geschäftsablauf betrifft, oder ein Deployment, das mehrere Dienste gleichzeitig berührt, eine Person erfordern, die das Risiko prüft und entscheidet, ob es weitergehen soll. Hier kommt die manuelle Freigabe ins Spiel.

Der Schlüssel ist: Automatisieren Sie, was objektiv messbar ist, und überlassen Sie subjektive Entscheidungen den Menschen. Wenn eine Prüfung als Regel formuliert werden kann, die immer gilt, automatisieren Sie sie. Wenn sie Kontext, Erfahrung oder Abwägungen erfordert, lassen Sie sie manuell.

Praxis-Checkliste für Ihre Pipeline-Gates

Wenn Sie Ihre Pipeline-Gates einrichten oder überprüfen, hier eine kurze Checkliste:

Das folgende Flussdiagramm zeigt, wie diese Gates zusammenarbeiten:

• Build-Gate: Stoppt die Pipeline, wenn der Code nicht kompiliert oder kein Artefakt erzeugt?
• Unit-Test-Gate: Prüfen die Tests sinnvolles Verhalten von relevanten Einstiegspunkten, nicht die interne Implementierung?
• Integrationstest-Gate: Testet die Pipeline gegen echte Abhängigkeiten (Datenbank, Queue, externer Dienst)?
• Security-Scan-Gate: Werden Abhängigkeiten auf Sicherheitslücken gescannt? Wird der Code auf Secrets und riskante Muster geprüft?
• Policy-Compliance-Gate: Werden Regeln wie Code-Review, Branch-Naming und Abhängigkeitsquellen automatisch durchgesetzt?

Nicht jedes Team braucht von Anfang an alle fünf. Starten Sie mit Build und Unit-Tests. Fügen Sie Integrationstests hinzu, wenn Sie externe Abhängigkeiten haben. Fügen Sie Security Scans hinzu, wenn Sie sich um Sicherheitslücken kümmern. Fügen Sie Policy-Prüfungen hinzu, wenn Sie Konsistenz im Team brauchen.

Der Sinn eines Gates ist es, Probleme zu stoppen, nicht Sie auszubremsen

Ein gut gestaltetes Gate erzeugt keine Reibung ohne Grund. Es fängt Probleme frühzeitig, wenn sie billig zu beheben sind. Ein fehlgeschlagener Build, der in der Pipeline abgefangen wird, kostet Minuten. Ein fehlgeschlagenes Deployment in der Produktion kostet Stunden, manchmal Tage.

Das Ziel ist nicht, die Pipeline schwerer passierbar zu machen. Das Ziel ist sicherzustellen, dass Sie deployen können, wenn die Pipeline grün ist. Wenn Ihre Pipeline grün ist, aber die Produktion trotzdem bricht, prüfen Ihre Gates die falschen Dinge. Reparieren Sie zuerst die Gates, dann die Pipeline.