Automatizace pipeline — co se spouští při každé změně, jak se nasazuje a jak se řídí release. Rozhoduje o tom, jak rychle a bezpečně se změny dostávají do produkce.

📊 Skóre

Stav	Počet
🟢 OK	5
🟠 Částečně	3
🔴 Špatně	1

Celkově: jádro pipeline je silné — lint, testy, licence, nasazení i notifikace selhání běží automaticky a pipeline se generuje per-aplikace. Slabší je bezpečnostní automatizace (skenování zranitelností jen naplánovaně) a verzování/release notes (manuální); zcela chybí automatické aktualizace závislostí.

🔍 Co jsme hodnotili

#	Položka	Stav
18	Lint + statická analýza na MR + prahy kvality	🟢
19	Automatizované testy + coverage na MR	🟢
20	Audit licencí závislostí	🟢
24	Automatizovaný deployment / release management	🟢
26	Notifikace selhání pipeline do komunikace	🟢
21	Report zranitelností závislostí (per MR)	🟠
23	Kontrola nepoužívaného kódu (knip/depcheck)	🟠
25	Automatizované verzování + release notes	🟠
22	Automatické MR s aktualizacemi závislostí	🔴

📌 Klíčové nálezy

🟢 Generovaná pipeline per aplikace

Kořenový .gitlab-ci.yml funguje jako parent pipeline, který přes trigger:include spouští child pipeline pro každou aplikaci (.gitlab/ci/tf-*.yml) — ty jsou generované vlastním pipeline-generátorem. Na merge requestu běží lint (ESLint, type-check, Prettier), testy s coverage reportem do MR, kontrola licencí a Sonar. Lint/type-check/prettier build blokují.

🟢 Automatizované nasazení

Deployment je plně automatizovaný přes kubectl set image: push do develop nasadí na staging, git tag release/<app>/* nasadí na produkci. Release je řízen konvencí tagů.

🟢 Notifikace selhání pipeline do Slacku

Selhání pipeline na develop posílá notifikaci do Slacku přes nativní GitLab → Slack integraci. Nastavení je na straně GitLab serveru (integrace projektu), proto není v repozitáři — tým se o spadlé pipeline na hlavní větvi dozví automaticky.

🟠 Skenování zranitelností jen naplánovaně

pnpm audit (--audit-level=high) existuje jako job report:audit, ale běží jen opt-in ve scheduled pipeline na develop, ne u každého merge requestu. V pipeline navíc není žádná šablona GitLab Dependency Scanning / SAST / Secret Detection. Nové zranitelné závislosti se tak zachytí až se zpožděním.

🟠 Kontrola mrtvého kódu jen částečná

Konzistenci generovaných artefaktů hlídají „drift" gaty (packages:dist-drift, api:spec-drift), ale chybí knip / depcheck / ts-prune — nepoužívané závislosti, soubory a exporty se nehlídají.

🟠 Manuální verzování a release notes

Není semantic-release ani changesets — verzování je manuální přes git tagy. Existuje generátor changelogu z ticketů, ale spouští se ručně a není napojen na CI. Release proces tak stojí na disciplíně, ne na automatizaci.

🔴 Bez automatických aktualizací závislostí

V projektu není Renovate ani Dependabot — aktualizace závislostí se neřeší automatickými merge requesty. Závislosti tak snáze zastarávají.

✅ Doporučení

Priorita	Doporučení
Vysoká	Zapojit skenování zranitelností do každého MR (GitLab Dependency Scanning nebo pnpm audit v MR pipeline).
Střední	Zavést Renovate/Dependabot pro automatické aktualizace závislostí.
Střední	Automatizovat verzování a release notes (semantic-release) a napojit generátor changelogu na CI.
Nízká	Rozšířit Slack notifikace i na produkční deploy (nejen develop).
Nízká	Doplnit knip pro detekci mrtvého kódu.