Quality Gates

Warum Quality Gates¶

Code Review faengt logische Fehler. Quality Gates fangen alles andere — automatisch, konsistent, bei jedem Commit. Ohne Ermuedung, ohne Uebersehen, ohne „dieses Mal lassen wir es durchgehen.”

Ohne Quality Gates verlassen Sie sich auf Disziplin. Disziplin versagt am Freitagnachmittag, unter Deadline-Druck, wenn „nur dieser kleine Fix” ohne Tests, ohne Review direkt in Produktion geht. Und am Montag haben Sie einen Incident.

Quality Gates verwandeln Best Practices in Policy. Wir sagen nicht „Sie sollten Tests schreiben” — wir sagen „ohne Tests kommt Code nicht in Produktion”. Wir sagen nicht „pruefen Sie Abhaengigkeiten” — wir sagen „eine kritische Schwachstelle = blockierter Merge.”

Ergebnis: konsistente Qualitaet unabhaengig davon, wer committed, wann committed wird und unter welchem Druck.

Anatomie einer CI/CD-Pipeline mit Quality Gates¶

Eine moderne CI/CD-Pipeline ist eine Reihe von Gates — jedes prueft einen anderen Qualitaetsaspekt. Fehlschlag an jedem Gate = blockiert.

Gate 1: Statische Analyse (30s-2min)¶

Linting: ESLint, Pylint, golangci-lint, SwiftLint. Konsistenter Code-Style, erkannte Anti-Patterns, potenzielle Bugs. Autofix wo moeglich.

Type Checking: TypeScript tsc --noEmit, mypy, Go Compiler. Typfehler sind die guenstigsten Bugs — in Sekunden erkannt, nicht in Stunden in Produktion.

Gate 2: Unit Tests (1-3min)¶

Die gesamte Unit-Test-Suite. Schnelles Feedback. Fehlschlag-Kriterium: Jeder Testfehler = blockiert. Kein „das ist ein Flaky Test, wir ignorieren ihn.” Ein Flaky Test wird entweder repariert oder geloescht.

Gate 3: Code Coverage (Teil der Unit Tests)¶

Gesamtabdeckung: Minimum 80% Zeilenabdeckung. Diff Coverage: Neuer Code im PR muss >90% Abdeckung haben. Critical Path Coverage: Business-Logik, Error Handling, sicherheitskritischer Code muss 100% Abdeckung haben.

Gate 4: Integrationstests (2-5min)¶

API-Contract-Tests, Datenbank-Integrationen, Service-zu-Service-Kommunikation.

Gate 5: Security Scanning (2-5min)¶

Dependency Scanning (SCA): Snyk, Dependabot, Trivy. Kritische/hohe Schwachstelle = blockierter Merge. SAST: Semgrep, CodeQL, SonarQube. Secret Detection: GitLeaks, TruffleHog. Container Scanning: Trivy, Snyk Container. Lizenz-Compliance: FOSSA, Snyk.

Gate 6: E2E Tests (3-10min)¶

Kritische User Flows end-to-end getestet. Playwright/Cypress gegen Staging-Umgebung.

Gate 7: Performance Check (optional, 2-5min)¶

k6 Smoke Test gegen Staging. Performance-Schwellenwerte — Latenz, Durchsatz.

Gate 8: Deployment Policy (Runtime)¶

Canary Deployment: Neue Version auf 5% des Traffics. Automatischer Rollback bei Anomalie. Progressiver Rollout: 5% → 25% → 50% → 100%.

Feature Flags: Neue Funktionalitaet hinter Feature Flag versteckt. Deployed in Produktion aber nur fuer internes Team sichtbar.

Deploy Windows: Definierte Fenster fuer Produktions-Deploys. Keine Deploys am Freitagnachmittag (ausser Hotfix).

Security Scanning in der Praxis¶

Triage-Workflow¶

1. Scan findet Finding — Schwachstelle, Secret, Anti-Pattern
2. Automatische Klassifizierung — Schweregrad (Critical, High, Medium, Low)
3. Critical/High: Blockierter Merge. Fix erforderlich vor Merge.
4. Medium: Warnung. Fix bis Sprintende erforderlich.
5. Low: Informell. Fix bei Gelegenheit.
6. False Positive: Unterdruecken mit Kommentar (warum). Regelmaessige Pruefung der Unterdrueckungen.

Shift-left Security¶

Security Scanning gehoert nicht nur in die CI-Pipeline. Wir integrieren es in den Entwickler-Workflow:

IDE-Plugins: Semgrep, Snyk IDE Extension — Echtzeit-Sicherheitsfeedback beim Codeschreiben.

Pre-commit Hooks: Secret Detection, grundlegendes SAST. Fehler vor dem Commit erkannt = null verschwendete CI-Zeit.

Deployment Policies¶

Progressive Delivery¶

Blue-Green Deployment: Zwei identische Produktionsumgebungen. Deploy auf die inaktive, Traffic umschalten. Sofortiger Rollback = zurueckschalten.

Canary Releases: Neue Version auf kleinem Prozentsatz des Traffics. Automatisierte Metrikanalyse. Anomalie = automatischer Rollback.

Feature Flags: Deploy von Release trennen. Code ist in Produktion, aber Feature ist aus. Aktivierung fuer spezifische Nutzer, Prozentsaetze, Segmente. Kill Switch fuer sofortiges Deaktivieren ohne Redeploy.

Rollback Policy¶

Jeder Deploy muss einen Rollback-Plan haben. Automatischer Rollback bei: - Fehlerrate > Schwellenwert (5x Baseline) - Latenz > Schwellenwert (3x Baseline) - Health Check Failure - Canary Analysis Failure

Rollback muss schneller als Fix Forward sein. Typischerweise < 5 Minuten.

Implementierungsplan¶

1. Audit — wir kartieren die aktuelle CI/CD-Pipeline und identifizieren Luecken
2. Quick Wins — Linting, Type Checking, Secret Detection (Tag 1-3)
3. Test Gates — Unit Tests, Coverage Thresholds (Woche 1-2)
4. Security Gates — SCA, SAST, Container Scanning (Woche 2-3)
5. E2E Gates — Playwright/Cypress in der Pipeline (Woche 3-4)
6. Deployment Policies — Canary, Feature Flags, Rollback-Automatisierung (Woche 4-6)
7. Monitoring — Gate-Metriken-Dashboard, Trendanalyse, Optimierung

Stack¶

CI/CD: GitHub Actions, GitLab CI, CircleCI, Azure DevOps.

Code-Qualitaet: SonarQube, ESLint, Pylint, golangci-lint.

Security: Snyk, Semgrep, CodeQL, Trivy, GitLeaks, FOSSA.

Coverage: Istanbul/nyc, coverage.py, JaCoCo, lcov.

Deployment: Argo Rollouts, Flagger, LaunchDarkly, Unleash.

Monitoring: Grafana, Prometheus — Gate Pass Rates, Pipeline-Dauertrends.

Verwandt mit