·
9 min
Quality Gates: Automatisierte Freigabe-Prüfungen in der CI/CD-Pipeline
Roman Kirchmeier - Autemos
Ein Quality Gate ist eine automatisierte Prüfschwelle in der CI/CD-Pipeline, die jede Codeänderung anhand fester Bedingungen freigibt oder stoppt. Erfüllt der Code alle Kriterien, läuft die Pipeline weiter. Verfehlt er auch nur eines, bricht der Build ab und das Release wird blockiert.
Mangelnde Softwarequalität kostete die US-Wirtschaft 2022 geschätzte 2,41 Billionen US-Dollar (CISQ, 2022). Solche Gates fangen genau diese Defekte ab, bevor sie in Produktion landen. Dieser Leitfaden zeigt, was ein Gate ausmacht, welche Kriterien hineingehören und wie Sie sinnvolle Schwellen statt Vanity-Werte definieren.
Kurz gefasst: Ein Quality Gate prüft jede Codeänderung automatisch gegen feste Bedingungen wie Testabdeckung, Fehlerzahl und Sicherheitschecks und blockiert die Freigabe bei einem Verstoß. SonarQube definiert es als „set of conditions against which the code is measured”. Gute Gates messen neuen Code statt die 100-Prozent-Abdeckung der gesamten Codebasis.
Abbildung 1: Ein Quality Gate verdichtet feste Bedingungen zu einem Ja oder Nein pro Codeänderung.
Was ist ein Quality Gate?
Ein Quality Gate ist eine Menge fester Freigabebedingungen, gegen die eine Pipeline jede Codeänderung automatisch misst. Bestanden bedeutet: weiter zum nächsten Schritt. Nicht bestanden bedeutet: Stopp.
Die SonarQube-Dokumentation formuliert es knapp: „A quality gate consists of a set of conditions against which the code is measured during analysis.” (SonarQube). Ein Gate beantwortet damit genau „one question: is my project ready for release?” (SonarQube).
Ein Gate ist kein einzelner Test. Es ist die Entscheidungsregel, die viele Testergebnisse und Analysewerte zu einem Ja oder Nein verdichtet. In einer Continuous-Testing-Pipeline sitzt es an den Übergängen zwischen Build, Test und Deployment.
Verwechseln Sie das Gate nicht mit der CI/CD-Pipeline selbst. Die Pipeline führt Schritte aus, das Gate entscheidet zwischen zwei Schritten über Weitergehen oder Stoppen. Ein Team kann mehrere Gates definieren: ein schnelles nach den Unit-Tests, ein strengeres vor dem Deployment in Produktion.
Welche Kriterien gehören in ein Quality Gate?
Abbildung 2: Typische Gate-Kriterien mit Beispielschwellen, die den neuen Code messen statt die Gesamtcodebasis.
In ein gutes Gate gehören messbare Kriterien wie Testabdeckung, Testerfolgsquote, statische Codeanalyse, Sicherheitsprüfungen und ein Performance-Budget. Jedes Kriterium bekommt eine klare Schwelle, ab der das Gate blockiert.
Der eingebaute „Sonar way”-Gate von SonarQube prüft vor allem neuen Code: null neue Issues, 100 Prozent geprüfte Security Hotspots sowie konfigurierbare Schwellen für Abdeckung und Duplizierung (SonarQube). Dieses Prinzip heißt „Clean as You Code”.
Die folgende Tabelle zeigt typische Gate-Kriterien mit Beispielschwellen und dem Grund dahinter.
Kriterium | Beispielschwelle | Warum |
|---|---|---|
Testabdeckung neuer Code | ≥ 80 % | Neue Logik ist getestet, ohne Altlasten zu blockieren |
Testerfolgsquote | 100 % grün | Ein einziger roter Test signalisiert ein offenes Risiko |
Neue statische Issues | 0 | Kein frischer Code-Smell oder Bug rutscht weiter |
Security Hotspots | 100 % geprüft | Jede sicherheitsrelevante Stelle ist bewertet |
Bekannte Schwachstellen | 0 kritisch/hoch | Keine ausnutzbare Lücke im Release |
Duplizierung neuer Code | < 3 % | Weniger Copy-Paste senkt die spätere Wartung |
Performance-Budget | z. B. LCP < 2,5 s | Regressionen in der Ladezeit fallen früh auf |
Nicht jedes Team braucht alle sieben Kriterien. Ein neues Web-Projekt startet oft mit Erfolgsquote, Abdeckung und statischer Analyse. Sicherheits- und Performance-Gates kommen dazu, sobald das Produkt in Produktion geht.
Trennen Sie harte von weichen Bedingungen. Eine harte Bedingung stoppt den Build sofort, etwa eine kritische Schwachstelle oder ein roter Kern-Test. Eine weiche Bedingung meldet nur eine Warnung, etwa eine leicht gesunkene Abdeckung. So bleibt das Gate streng dort, wo es zählt, und tolerant beim Rest.
Wie funktioniert ein Quality Gate in der Pipeline?
Abbildung 3: Ein Gate durchläuft in der Pipeline vier Schritte von der Prüfung bis zur Freigabe oder zum Stopp.
Ein Gate durchläuft in der Pipeline vier Schritte: Prüfungen ausführen, Ergebnisse einsammeln, gegen die Schwellen bewerten und den Build freigeben oder stoppen. Der Ablauf ist immer gleich, egal ob Unit-, Integrations- oder E2E-Stufe.
Prüfungen ausführen. Nach dem Build laufen Tests, statische Analyse und Sicherheitsscans automatisch an.
Ergebnisse einsammeln. Die Pipeline sammelt Abdeckung, Fehlerzahl und Reportdaten aus allen Läufen ein.
Gegen die Schwellen bewerten. Jeder Wert wird gegen seine definierte Schwelle geprüft.
Freigeben oder blockieren. Sind alle Bedingungen erfüllt, geht der Build weiter. Sonst stoppt die Pipeline.
Jenkins zeichnet Testergebnisse nach jedem Lauf auf und markiert den Build bei fehlgeschlagenen Tests als UNSTABLE (Jenkins). So bleibt auch bei einem roten Gate der Trend sichtbar, statt dass die Pipeline nur kommentarlos abbricht.
Die Platzierung entscheidet über die Feedback-Geschwindigkeit. Frühe Gates prüfen schnelle Unit-Tests und statische Analyse in Minuten, damit Entwickler den Fehler sofort sehen. Späte Gates prüfen langsamere E2E-, Sicherheits- und Performance-Läufe kurz vor dem Deployment. Ein Gate direkt nach jedem Commit hält die Rückmeldung kurz und den Fehler klein.
Welche Quality Gates sind sinnvoll und welche nicht?
Sinnvolle Gates messen neuen Code und blockieren echte Risiken; unsinnige Gates fordern Vanity-Werte wie 100 Prozent Abdeckung der gesamten Codebasis. Ein hoher Prozentwert allein sagt wenig über die Testqualität aus.
Eine Gate-Regel auf 100 Prozent Testabdeckung der Gesamtcodebasis klingt streng, erzeugt in der Praxis aber vor allem Scheintests ohne echte Aussagen. Das „Clean as You Code”-Prinzip von SonarQube setzt genau hier an: Es misst die Abdeckung des neuen Codes und lässt bestehende Altlasten unangetastet (SonarQube). Frühe Prüfungen aus dem Shift-Left-Testing liefern dem Gate saubere Ergebnisse, lange bevor eine Änderung den Merge erreicht.
Diese Muster führen zu Gates, die mehr Frust als Nutzen bringen:
Abdeckung der Gesamt-Codebasis statt des neuen Codes als harte Schwelle
Flaky Tests, die das Gate zufällig rot färben und Vertrauen kosten
Zu viele Kriterien auf einmal, sodass niemand mehr den Grund für einen roten Build kennt
Schwellen, die ohne Konsens im Team gesetzt wurden und deshalb umgangen werden
Ein gutes Gate ist streng bei neuem Code, tolerant gegenüber Altlasten und für jeden im Team nachvollziehbar.
Schwellen sind kein einmaliger Beschluss. Starten Sie bewusst niedriger, etwa 70 Prozent Abdeckung auf neuem Code, und ziehen Sie den Wert an, sobald das Team die Disziplin hält. Ein Gate, das die Hälfte der Merges grundlos blockiert, wird umgangen und verliert seine Wirkung.
Wie helfen Quality Gates in regulierten Branchen?
Abbildung 4: Mangelnde Softwarequalität kostete die US-Wirtschaft 2022 geschätzte 2,41 Billionen US-Dollar (CISQ).
In regulierten Branchen liefern Gates den nachweisbaren Beleg, dass jedes Release definierte Qualitäts- und Sicherheitskriterien erfüllt hat. Das Gate-Ergebnis wird zum archivierbaren Freigabe-Nachweis für Audits.
In Kundenprojekten sehen wir, dass Banken das protokollierte Gate-Ergebnis pro Release aufbewahren, um gegenüber Prüfern lückenlos zu belegen, welche Tests bestanden wurden. Wie das in der Praxis mit Audit-Trails und Vier-Augen-Prinzip zusammenspielt, zeigt der Beitrag zur Testautomatisierung in regulierten Banken.
Ein Gate in einer regulierten Pipeline ersetzt oft manuelle Freigabeprotokolle. Statt einer Unterschrift auf Papier hält das System pro Release fest, welche Kriterien erfüllt waren, wann und mit welchem Ergebnis. Das Vier-Augen-Prinzip bleibt als Review-Schritt bestehen, doch die technische Prüfung läuft reproduzierbar und ohne Lücken.
Die Evidenz zählt nur, wenn die Tests dahinter verlässlich laufen. DORA verbindet kontinuierliches Testen mit „a low error rate in production” (DORA, 2024). Autemos ist eine KI-gestützte Testautomatisierung, die Tests über Web, Mobile, API und Desktop in einer Pipeline ausführt. Mit dem AI Recorder aufgezeichnete Tests laufen direkt in der CI/CD-Strecke und erzeugen wiederholbare Report-Daten, die ein Gate auswerten kann.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem Quality Gate und einem Test?
Ein Test prüft ein einzelnes Verhalten und liefert ein Ergebnis; ein Gate fasst viele solcher Ergebnisse plus Analysewerte zu einer Freigabe-Entscheidung zusammen. Der Test sagt „grün oder rot”, das Gate sagt „release-fähig oder nicht”.
Sollte ein Quality Gate den Build bei jedem Fehler blockieren?
Ein Gate sollte bei echten Risiken blockieren, nicht bei jedem Rauschen. Fehlgeschlagene Sicherheits- oder Kern-Tests stoppen den Build; instabile Flaky Tests gehören in eine Quarantäne, damit sie das Gate nicht zufällig rot färben und das Vertrauen untergraben.
Welche Testabdeckung sollte ein Quality Gate verlangen?
Ein Gate sollte die Abdeckung des neuen Codes messen, üblich sind etwa 80 Prozent. Eine harte 100-Prozent-Schwelle auf die gesamte Codebasis erzeugt vor allem Scheintests. Das „Clean as You Code”-Prinzip von SonarQube prüft deshalb gezielt den frisch geänderten Code.
Wo im CI/CD-Prozess sitzt ein Quality Gate?
Ein Gate sitzt an den Übergängen der Pipeline: nach dem Build, nach der Integrationsstufe und vor dem Deployment. Frühe Gates prüfen Unit-Tests und statische Analyse, späte Gates prüfen E2E-, Sicherheits- und Performance-Kriterien vor der Freigabe.
Sind Quality Gates in regulierten Branchen vorgeschrieben?
Kein Gesetz nennt „Quality Gate” wörtlich, doch regulierte Branchen verlangen nachvollziehbare Freigabe-Nachweise. Ein automatisiertes Gate liefert genau diese Evidenz pro Release und ersetzt manuelle Freigabeprotokolle durch reproduzierbare, archivierbare Prüfergebnisse.
Fazit
Ein Quality Gate macht die Release-Entscheidung objektiv: feste Kriterien, klare Schwellen, ein automatisches Ja oder Nein. Die stärksten Gates messen neuen Code, blockieren echte Risiken und bleiben für das ganze Team nachvollziehbar. Vanity-Werte wie 100 Prozent Abdeckung der Gesamtcodebasis kosten Zeit, ohne die Qualität zu heben.
Bei geschätzten 2,41 Billionen US-Dollar Kosten durch mangelnde Softwarequalität (CISQ, 2022) zahlt sich jede blockierte Fehlfreigabe aus. In regulierten Branchen liefern Gates zusätzlich den Audit-Nachweis, den Prüfer erwarten.
Möchten Sie sinnvolle Quality Gates in Ihre Pipeline einbauen und Tests über alle Plattformen automatisieren? Sprechen Sie mit unserem Team über Ihren konkreten CI/CD-Aufbau.
