🚦 Quality Gates richtig definieren (Praxisleitfaden)
Quality Gates sind keine Bürokratie.
Sie sind ein gezielter Kontrollpunkt, um bekannte Fehlerklassen vor dem Merge/Release zu stoppen.
Ein Gate ist dann gut, wenn es:
- klar ist (was wird geprüft, warum?)
- wirksam ist (reduziert es ein echtes Risiko?)
- pragmatisch ist (geringer Overhead, stabil, nachvollziehbar)
- skalierbar ist (Teams können es dauerhaft einhalten)
Ein Gate ersetzt keine Verantwortung – es unterstützt sie.
1. Grundprinzip: Gates schützen vor teuren Fehlern
Ein Gate soll nie „Qualität erzwingen“, sondern Risiko reduzieren:
- Bugs verhindern → Reliability Gate
- Security-Risiken stoppen → Security Gate
- Unkontrollierte Änderungen vermeiden → Review/Traceability Gate
- Regressionen früh finden → Test Gate
Wenn ein Gate keinen klaren Risikobeitrag hat, wird es ignoriert.
2. Startpunkt: New Code statt Legacy
Der häufigste Fehler bei Sonar ist:
Gate auf den gesamten Bestand anwenden, obwohl Legacy-Schulden existieren.
Das führt zu:
- permanent rotem Dashboard
- Tool-Resignation
- massenhaft „Won’t Fix“
Empfehlung:
- Baseline setzen (Status quo akzeptieren)
- New Code Gate aktivieren (ab jetzt keine neuen Schulden)
- Schulden gezielt abbauen (separates Backlog)
3. Gate-Design: Welche Dimension wird geschützt?
Ein sinnvolles Gate-Set ist klein.
Empfehlung: 4 Gate-Kategorien
- Build & Lint (Determinismus, Konsistenz)
- Tests (Regressionen, Change Safety)
- Security (Vulnerabilities, Hotspots)
- Maintainability (Komplexität, Duplication, neue Smells)
Alles andere sind Erweiterungen, nicht der Kern.
4. Minimal sinnvolles Gate-Set (praxisbewährt)
4.1 Build & Lint (Pflicht)
- Build erfolgreich
- Lint ohne Errors
- Formatierung (Prettier) erfüllt
Warum: verhindert triviale Fehlerklassen und Review-Reibung.
4.2 Tests (New Code)
- Unit Tests müssen laufen
- Minimum für neue/angepasste Logik
- bevorzugt: Diff-Coverage statt globaler Coverage
Warum: verhindert Regressionen und schützt Changeability.
Praxisregel:
Keine neue Logik ohne Testnachweis (Unit oder Integration).
4.3 Security (hart)
- keine neuen Vulnerabilities
- Security Hotspots müssen reviewed werden
- Dependency Scan ohne Criticals (je nach Risiko)
Warum: Security Findings sind selten „nur Qualität“ – sie sind Risiko.
Security ist die Gate-Kategorie, bei der „tolerieren“ am teuersten ist.
4.4 Maintainability (realistisch)
- keine neuen Bugs
- keine neuen Blocker/Critical Code Smells
- Duplication auf neuem Code begrenzen
- Komplexität pro Funktion begrenzen (optional)
Warum: reduziert schleichende Wartungskosten.
5. Konkrete Gate-Empfehlungen (Sonar-orientiert)
Diese Werte sind Richtwerte, nicht Dogma.
Für Stufe 2 (Team-Standard)
New Code Gate
- Reliability: A (keine neuen Bugs)
- Security: A (keine neuen Vulnerabilities)
- Maintainability: A oder B (keine neuen Critical Smells)
- Coverage on New Code: z. B. ≥ 70% (oder Diff-Coverage)
- Duplication on New Code: z. B. ≤ 3%
Für Stufe 3 (Produktionsreife)
Wie Stufe 2 plus:
- Security Hotspots: 100% reviewed
- Coverage on New Code: höher (z. B. ≥ 80% je nach Domäne)
- Komplexitäts-Limits für kritische Module
- Integrations-/E2E Gates für kritische Flows (pipeline-seitig)
Für Stufe 4/5 (High Assurance / Reguliert)
Wie Stufe 3 plus:
- Traceability Gate: Ticket ↔ PR ↔ Release muss existieren
- Evidence Gate: Testberichte / Signaturen / Artefakte versioniert
- Separation of Duties Gate (prozessual)
- Kein „Won’t Fix“ ohne formale Begründung
6. Umgang mit Findings: Regeln statt Bauchgefühl
Ein Gate braucht auch Regeln für den Alltag.
6.1 „Fix, Defer, Accept“ als Standard
Jedes Finding muss eine Entscheidung bekommen:
- Fix: jetzt beheben
- Defer: bewusst verschieben (Ticket + Termin)
- Accept: bewusst akzeptieren (Risiko dokumentiert)
„Ignorieren“ ist keine Option.
6.2 Wann darf man ein Finding akzeptieren?
Akzeptanz ist nur legitim, wenn:
- Risiko gering oder nicht relevant
- Aufwand unverhältnismäßig
- es keine bessere Alternative gibt
- es dokumentiert ist (Begründung)
Bei Security Findings ist Akzeptanz die Ausnahme.
7. Anti-Patterns (die Gates zerstören)
- Gate ist ständig rot → niemand nimmt es ernst
- zu viele Regeln → Regelmüdigkeit
- Coverage als KPI → sinnlose Tests
- “Won’t Fix” als Default → Schein-Compliance
- Alles ist „Critical“ → nichts ist kritisch
Gates müssen glaubwürdig bleiben.
8. Iterative Einführung (empfohlen)
Ein Gate-System ist ein Produkt.
Statt Big Bang:
- Build/Lint Gate
- Security Gate
- New Code Maintainability Gate
- New Code Coverage Gate
- Erweiterungen für Stufe 3+
So bleibt die Organisation handlungsfähig.
9. Definition of Done für Gates
Ein Projekt hat funktionierende Gates nur dann, wenn:
- jeder Merge durch die Gates muss
- rote Gates keine Ausnahme sind
- Findings aktiv entschieden werden
- Regeln dokumentiert und verständlich sind
- Teams nicht „Workarounds“ als Normalität nutzen
Kernaussage
Quality Gates sind wirksam, wenn sie:
- auf New Code fokussieren
- Security & Bugs strikt behandeln
- Maintainability realistisch steuern
- Entscheidungen erzwingen (Fix/Defer/Accept)
- dauerhaft akzeptiert werden
Ein Gate-System ist kein Kontrollinstrument.
Es ist ein Mechanismus, um Qualität über Zeit stabil zu halten.