# Quality Gates in der CI/CD-Pipeline: Aufbau in vier Stufen *Quelle: https://www.provimedia.de/blog/quality-gates-ci-cd-pipeline · Stand: 2026-07-27* > Eine Pipeline, die nur baut und ausliefert, ist ein Förderband. Wie aus ihr eine Prüfkette wird, die schnell bleibt und trotzdem anhält. **Eine wirksame Prüfkette verteilt sich auf vier Stufen: Sekunden beim Commit, Minuten beim Pull Request, gründlich vor dem Merge, hart vor dem Deploy. Die Reihenfolge folgt einem einzigen Prinzip — je früher ein Fehler auffällt, desto billiger ist er, also gehört jede Prüfung so weit nach vorne, wie ihre Laufzeit es erlaubt.** ## Wie baue ich Quality Gates in eine CI/CD-Pipeline ein? **In vier Stufen mit klarem Zeitbudget je Stufe.** Das Budget ist wichtiger als die Vollständigkeit: Eine Pipeline, die vierzig Minuten braucht, wird umgangen. Stufe Zeitbudget Prüfungen 1 — beim Commit (lokal) unter 10 Sekunden Formatierung, Linter auf geänderten Dateien, Geheimnis-Scan 2 — beim Push / Pull Request unter 5 Minuten Unit-Tests, statische Analyse, Abdeckung der geänderten Zeilen, Abhängigkeitsprüfung 3 — vor dem Merge unter 20 Minuten Integrationstests, End-to-End-Tests der Hauptpfade, Build 4 — vor dem Deploy so lange wie nötig Migrationsprüfung, Dateiklassifizierung, Rückrollweg, Smoke-Tests nach dem Ausrollen ## Welche Prüfung gehört in welche Stufe? **Die Zuordnung folgt der Laufzeit, nicht der Wichtigkeit.** Eine wichtige Prüfung, die zehn Minuten braucht, gehört trotzdem nicht in Stufe 1 — sonst wird Stufe 1 abgeschaltet und alle Prüfungen darin gehen mit verloren. - **Stufe 1 muss unbemerkt bleiben.** Was hier länger als ein paar Sekunden dauert, wird als Störung empfunden. Prüfen Sie nur die geänderten Dateien, nicht das Projekt. - **Stufe 2 ist das eigentliche Qualitätstor.** Hier entscheidet sich, ob eine Änderung überhaupt zur Diskussion steht. Alles, was maschinell entscheidbar ist, gehört hierher — damit im Review nur die Fragen übrig bleiben, für die man einen Menschen braucht. - **Stufe 3 darf teuer sein, weil sie selten läuft.** Integrationstests gegen echte Abhängigkeiten, Tests der Hauptpfade im Browser. - **Stufe 4 ist keine Codeprüfung.** Hier geht es um den Vorgang selbst — dazu unten mehr. ## Wie bleibt die Pipeline schnell? **Mit vier Maßnahmen, die zusammen den Unterschied zwischen zwanzig Minuten und drei ausmachen.** - **Nur prüfen, was sich geändert hat.** Statische Analyse und Linter brauchen den Diff, nicht das Repository. - **Zwischenstände zwischenspeichern.** Abhängigkeiten und Build-Artefakte gehören in den Cache, nicht in jeden Lauf. - **Parallel statt nacheinander.** Tests, Analyse und Build haben keine Reihenfolge-Abhängigkeit. - **Früh abbrechen.** Wenn der Linter in Sekunde drei scheitert, muss die zwölfminütige Testsuite nicht mehr laufen. ## Warum ist das Deploy-Gate das wichtigste? **Weil es die einzige Stufe ist, an der ein Fehler nicht nur teuer, sondern sofort sichtbar ist.** Ein durchgerutschter Code-Smell kostet in einem halben Jahr Zeit. Eine nicht umkehrbare Migration oder eine mitgelieferte Datei, die nie auf einen Server gehört, kostet heute Abend. Ein Deploy-Gate prüft deshalb andere Dinge als die Stufen davor: - **Was wird eigentlich übertragen?** Jede Datei im Übertragungsumfang gehört klassifiziert: gehört auf den Server, gehört nur lokal hin, darf nie auf einen Server. Konfigurationsdateien, Zugangsdaten, Entwicklungswerkzeuge fallen in die dritte Gruppe. - **Ist eine Schema-Änderung dabei, und ist sie umkehrbar?** Eine Migration ohne Gegenstück ist eine Einbahnstraße. Vorher: Sicherung nachweisen. - **Gibt es einen Rückrollweg, und wurde er getestet?** Ein nie erprobter Rückrollweg ist eine Vermutung. - **Läuft danach etwas, das den Erfolg prüft?** Ein Smoke-Test nach dem Ausrollen ist der Unterschied zwischen „ausgeliefert" und „funktioniert". Keine dieser vier Fragen lässt sich durch mehr Tests beantworten — sie betreffen den Vorgang, nicht den Code. Deshalb braucht Stufe 4 eine eigene Schranke, siehe [Was ist ein Quality Gate](/blog/was-ist-ein-quality-gate). ## Wie führe ich Gates ein, ohne den laufenden Betrieb zu blockieren? **Zuerst beobachtend, dann blockierend — und immer nur für neuen Code.** - **Woche 1 bis 2: nur melden.** Alle Prüfungen laufen, keine bricht ab. Sie sehen, wie oft welches Kriterium anschlagen würde. - **Woche 3: die klaren Fälle scharf stellen.** Fehlschlagende Tests und Geheimnisse im Code brechen ab. Gegen diese beiden argumentiert niemand. - **Danach: Basislinie ziehen und Neues verschärfen.** Der Bestand wird eingefroren, für geänderte Zeilen gilt die volle Strenge. Vorgehen im Beitrag zur [statischen Codeanalyse](/blog/statische-codeanalyse-tools-vergleich). ## Häufige Fragen zu Quality Gates in der Pipeline ### Was ist der Unterschied zwischen CI und CD? Continuous Integration bezeichnet das häufige Zusammenführen und automatische Prüfen von Änderungen. Continuous Delivery beziehungsweise Deployment bezeichnet das automatisierte Ausliefern des geprüften Stands. Die Gates aus Stufe 1 bis 3 gehören zur CI, Stufe 4 zur CD. ### Sollte die Pipeline bei jedem Analysebefund abbrechen? Nein, nur oberhalb einer festgelegten Schwere und nur bei neuen Befunden. Wer bei jeder Stilanmerkung abbricht, erzeugt Umgehungen statt Qualität. ### Wie gehe ich mit unzuverlässigen Tests um? Als eigenes Problem behandeln, nicht als Rauschen. Ein Test, der gelegentlich grundlos rot ist, kostet mehr als er nützt: Er trainiert das Team darauf, rote Läufe zu wiederholen statt sie zu lesen. Entweder reparieren oder entfernen. ### Brauche ich für Stufe 1 einen Git-Hook? Ein lokaler Hook ist der übliche Weg, aber er ist umgehbar und liegt auf dem Rechner des Einzelnen. Verlassen Sie sich nicht allein darauf — was in Stufe 1 geprüft wird, sollte in Stufe 2 noch einmal laufen. > Welche Datei in Ihrem letzten Deploy hatte auf dem Server eigentlich nichts verloren? Wenn Sie das nicht auf Anhieb beantworten können, ist genau das die Lücke. [Code Guardian](/code-guardian) klassifiziert jede Datei im Übertragungsumfang und behandelt jede Migration als irreversibel, bis das Gegenteil belegt ist. ## Quellen - OWASP Top 10:2025, Kategorie A03 „Software Supply Chain Failures" (Begründung der Abhängigkeitsprüfung in Stufe 2). - ISO/IEC 25010:2023 (Qualitätsmerkmale als Bezugsrahmen für Gate-Kriterien). *Stand: 27. Juli 2026. Allgemeine fachliche Einordnung; konkrete Zeitbudgets hängen von Projektgröße und Infrastruktur ab.* --- Kanonische Version: