Quality Gates

Proč quality gates¶

Code review chytí logické chyby. Quality gates chytí všechno ostatní — automaticky, konzistentně, při každém commitu. Bez únavy, bez přehlédnutí, bez „tentokrát to projde”.

Bez quality gates spoléháte na disciplínu. Disciplína selže v pátek odpoledne, pod tlakem deadlinu, kdy „jen tenhle malý fix” projde bez testů, bez review, rovnou do produkce. A v pondělí řešíte incident.

Quality gates přeměňují best practices na policy. Neříkáme „měli byste psát testy” — říkáme „bez testů se kód nedostane do produkce”. Neříkáme „zkontrolujte závislosti” — říkáme „kritická vulnerability = blocked merge”.

Výsledek: konzistentní kvalita nezávislá na tom, kdo commituje, kdy commituje a pod jakým tlakem.

Anatomy CI/CD pipeline s quality gates¶

Moderní CI/CD pipeline je sada gates — každý kontroluje jiný aspekt kvality. Fail na kterémkoliv gate = blocked.

Gate 1: Static analysis (30s-2min)¶

Linting: ESLint, Pylint, golangci-lint, SwiftLint. Konzistentní code style, caught anti-patterns, potenciální bugy. Autofix kde možné — formatování opravíme automaticky, vývojář řeší jen reálné problémy.

Type checking: TypeScript tsc --noEmit, mypy, Go compiler. Type errors jsou cheapest bugs to fix — chytíte je za sekundy, ne za hodiny v produkci.

Dead code detection: Nepoužívané importy, nedosažitelný kód, unused variables. Čistý codebase je udržovatelný codebase.

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

Celá unit test suite. Rychlý feedback — vývojář ví za minuty, jestli něco rozbil. Paralelizace pro velké test suites.

Fail criteria: Jakýkoliv test failure = blocked. Žádné „to je flaky test, ignorujeme”. Flaky test se buď opraví, nebo smaže. Flaky testy ničí důvěru v celou test suite.

Gate 3: Code coverage (součást unit testů)¶

Coverage report generovaný během test runu. Threshold enforcement:

Celková coverage: Minimum 80% line coverage. Merge blocked pod threshold.

Diff coverage: Nový kód v PR musí mít coverage >90%. Staré dluhy neblokují nový vývoj, ale nový kód musí být testovaný.

Critical path coverage: Business logika, error handling, security-sensitive kód musí mít 100% coverage. Identifikováno přes code owners nebo path patterns.

Gate 4: Integrační testy (2-5min)¶

API contract testy, databázové integrace, service-to-service komunikace. Testovací prostředí spuštěné v CI (Docker Compose, testcontainers).

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

Několik vrstev security kontrol:

Dependency scanning (SCA): Snyk, Dependabot, Trivy. Kontrola known vulnerabilities v závislostech. Critical/High vulnerability = blocked merge. Medium/Low = warning, fix do sprintu.

SAST (Static Application Security Testing): Semgrep, CodeQL, SonarQube. Analýza zdrojového kódu pro security anti-patterns — SQL injection, XSS, hardcoded secrets, insecure deserialization.

Secret detection: GitLeaks, TruffleHog. Skenování commitů pro API keys, passwords, tokens. Jeden commitnutý secret = compromised secret. Prevence je nekonečně levnější než rotace.

Container scanning: Trivy, Snyk Container. Vulnerabilities v base images, misconfigured Dockerfiles. Outdated base image s known CVE = blocked build.

License compliance: FOSSA, Snyk. Kontrola licencí závislostí. GPL v komerčním projektu? Flagged.

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

Kritické uživatelské flow testované end-to-end. Playwright/Cypress against staging environment. Smoke test subset — ne celá E2E suite, ale kritické paths.

Gate 7: Performance check (volitelný, 2-5min)¶

k6 smoke test against staging. Performance thresholds — latency, throughput. Regression v response time = warning nebo block.

Gate 8: Deployment policy (runtime)¶

Poslední gate před produkcí:

Canary deployment: Nová verze na 5% provozu. Monitoring error rate, latency. Automatický rollback při anomálii. Progressivní rollout: 5% → 25% → 50% → 100%.

Feature flags: Nová funkce skrytá za feature flag. Deploy do produkce, ale viditelná jen pro interní tým. Postupné zapínání pro segmenty uživatelů.

Deploy windows: Definované okna pro produkční deploy. Žádné deploye v pátek odpoledne (pokud to není hotfix). Žádné deploye během peak hours bez explicitního schválení.

Required approvals: Pro kritické služby — manuální approval po automatických gates. Two-person rule pro infrastructure changes.

Code coverage — správně¶

Coverage je užitečná metrika, když ji používáte správně. A zbytečná, když ji gamifikujete.

Co coverage měří¶

Line coverage: Kolik řádků kódu bylo spuštěno během testů. Nejběžnější, nejjednodušší, ale nejméně informativní.

Branch coverage: Kolik větví (if/else, switch cases) bylo testováno. Lepší — odhalí netestované edge cases.

Function coverage: Kolik funkcí bylo voláno. Užitečné pro high-level přehled.

Mutation coverage: Nejpřísnější. Zmutuje kód (změní > na <, odstraní řádek) a kontroluje, jestli testy selžou. Pokud mutace projde testy = test je slabý. Náročné na compute, ale odhalí skutečnou kvalitu testů.

Coverage anti-patterns¶

Testing for coverage, not correctness: Testy, které projdou kódem bez meaningful assertions. Line se spustí, coverage stoupne, ale test nic neověří.

100% coverage obsession: Testování trivialního kódu (constructors, getters) na úkor komplexní business logiky. 80% coverage s kvalitními testy > 100% coverage s prázdnými assertions.

Coverage ratchet bez nuance: „Coverage nesmí klesnout” jako absolut. Někdy refaktoring smaže testovaný kód a coverage klesne. To je OK — diff coverage řeší nový kód, celková coverage se řeší strategicky.

Security scanning v praxi¶

Security scanning bez procesu generuje šum. S procesem zachytává vulnerabilities dřív, než se dostanou do produkce.

Triage workflow¶

1. Scan najde finding — vulnerability, secret, anti-pattern
2. Automatická klasifikace — severity (Critical, High, Medium, Low)
3. Critical/High: Blocked merge. Fix required před merge.
4. Medium: Warning. Fix required do konce sprintu. Tracked v backlogu.
5. Low: Informational. Fix při příležitosti.
6. False positive: Suppress s komentářem (proč). Pravidelný review suppressions.

Shift-left security¶

Security scanning nepatří jen do CI pipeline. Integrujeme ho do vývojářského workflow:

IDE pluginy: Semgrep, Snyk IDE extension — security feedback v reálném čase během psaní kódu.

Pre-commit hooks: Secret detection, basic SAST. Chyby chycené před commitem = zero CI time wasted.

PR review: Security bot komentuje PR s findings. Vývojář vidí kontext přímo v code review.

Deployment policies¶

Quality gates v CI chrání kód. Deployment policies chrání produkci.

Progressive delivery¶

Blue-green deployment: Dvě identické produkční prostředí. Deploy na neaktivní, přepnutí traffic. Instant rollback = přepnutí zpět.

Canary releases: Nová verze na malém procentu provozu. Automatizovaná analýza metrik. Anomálie = automatický rollback. Progressivní rozšiřování.

Feature flags: Oddělení deploy od release. Kód je v produkci, ale funkce je vypnutá. Zapnutí pro specifické uživatele, procenta, segmenty. Kill switch pro okamžité vypnutí bez redeploye.

Rollback policy¶

Každý deploy musí mít rollback plán. Automatický rollback při: - Error rate > threshold (5× baseline) - Latency > threshold (3× baseline) - Health check failure - Canary analysis failure

Rollback musí být rychlejší než fix forward. Typicky < 5 minut.

Implementační plán¶

1. Audit — zmapujeme současný CI/CD pipeline, identifikujeme mezery
2. Quick wins — linting, type checking, secret detection (den 1-3)
3. Test gates — unit testy, coverage thresholds (týden 1-2)
4. Security gates — SCA, SAST, container scanning (týden 2-3)
5. E2E gates — Playwright/Cypress v pipeline (týden 3-4)
6. Deployment policies — canary, feature flags, rollback automation (týden 4-6)
7. Monitoring — gate metrics dashboard, trend analysis, optimization

Stack¶

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

Code quality: 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 duration trends.

Souvisí s