42. Principy CI/CD a proč jsou klíčové pro DevOps

Úvod a kontext

Ve všech předchozích lekcích jsme používali nástroje ručně: git push,
docker build, kubectl apply, helm upgrade. To funguje pro
studijní účely, ale v reálném týmu s desítkami commitů denně je ruční
opakování stejných kroků pomalé, chybové a nekonzistentní — jeden
člověk zapomene spustit testy, druhý nasadí ze špatné větve. CI/CD
(Continuous Integration / Continuous Delivery nebo Deployment) je
praxe automatizace těchto kroků do opakovatelné, spolehlivé
pipeline, která se spouští automaticky při každé změně kódu.

Teorie

Continuous Integration (CI)

Continuous Integration znamená, že vývojáři často (ideálně
několikrát denně) slučují svou práci do sdílené větve, a při každém
takovém sloučení se automaticky:

1. zkompiluje/sestaví kód,
2. spustí automatické testy,
3. zkontroluje kvalita kódu (linting, statická analýza).

Cíl je najít problém co nejdřív — pokud dva vývojáři udělají
neslučitelné změny nebo někdo rozbije testy, CI to odhalí během minut,
ne až za týden při ručním testování před vydáním. Bez CI se problémy
integrace hromadí a jejich řešení je exponenciálně dražší, čím později
se odhalí ("merge hell").

Continuous Delivery vs. Continuous Deployment

Tyto dva pojmy se často pletou, ale mají odlišný rozsah automatizace:

• Continuous Delivery — každá změna, která projde CI (build +
  testy), je automaticky připravena k nasazení (např. sestavený a
  otestovaný artefakt/image čeká v registru) — ale samotné nasazení do
  produkce vyžaduje ruční schválení (kliknutí "deploy" nebo
  schválení pull requestu).
• Continuous Deployment — jde o krok dál: každá změna, která projde
  CI, se automaticky nasadí až do produkce, bez ručního zásahu.
  Vyžaduje vysokou důvěru v testovací pokrytí, protože chyba se dostane
  do produkce velmi rychle.

Volba mezi Delivery a Deployment je otázka rizika a vyspělosti procesu
— týmy s vysokým pokrytím testy a dobrým monitoringem (viz pozdější
lekce o SRE) si mohou dovolit plné Continuous Deployment.

Pipeline jako sled fází

CI/CD pipeline je typicky sled fází, kde další fáze proběhne jen pokud
předchozí uspěla:

commit/push → build → unit testy → integrační testy → sestavení
image → bezpečnostní sken → nasazení do staging → (schválení) →
nasazení do produkce

Pokud kterákoliv fáze selže, pipeline se zastaví a tým dostane
okamžitou zpětnou vazbu (notifikace, červený status u commitu) — změna
se dál nešíří.

Proč je to klíčové pro DevOps

CI/CD je prakticky operacionalizace filozofie DevOps — sbližuje
vývoj (Dev) a provoz (Ops) tím, že:

• zkracuje čas mezi napsáním kódu a jeho reálným nasazením (lead time),
• snižuje riziko každého jednotlivého nasazení (menší, častější změny
  jsou snazší k analýze než jedna velká "release" jednou za měsíc),
• nahrazuje ruční, nekonzistentní kroky reprodukovatelnou automatizací,
• dává rychlou zpětnou vazbu vývojářům, dokud mají kontext v hlavě.

Kde pipeline běží

Pipeline definice žije typicky přímo v repozitáři vedle kódu (viz
"pipeline jako kód" v pozdější lekci) a spouští ji CI/CD platforma —
nejrozšířenější jsou GitHub Actions, GitLab CI/CD, Jenkins nebo
CircleCI. Platforma poskytuje izolované spouštěcí prostředí (runner) —
obvykle čistý kontejner nebo virtuální stroj — pro každý běh, aby
výsledek nezávisel na tom, co zůstalo nastavené z minulého běhu.

Praktický příklad

Konceptuální znázornění pipeline pro webovou aplikaci (podrobná
implementace v GitHub Actions je předmětem další lekce):

Trigger: push do větve main
  │
  ├─ Stage: build
  │    → nainstalovat závislosti, zkompilovat/sestavit aplikaci
  │
  ├─ Stage: test
  │    → spustit unit testy; pipeline se zastaví, pokud test selže
  │
  ├─ Stage: package
  │    → sestavit Docker image, otagovat commit hashem
  │
  ├─ Stage: deploy-staging
  │    → nasadit image do staging clusteru (automaticky)
  │
  └─ Stage: deploy-production
       → nasadit do produkce
       (Continuous Delivery: čeká na ruční schválení)
       (Continuous Deployment: proběhne automaticky)

Shrnutí

Continuous Integration automatizuje časté slučování, build a testování
kódu, aby se problémy odhalily co nejdřív. Continuous Delivery jde dál
a udržuje kód neustále připravený k nasazení, zatímco Continuous
Deployment nasazuje automaticky až do produkce bez ručního schválení.
Pipeline je sled fází, které na sebe navazují a při selhání se
zastaví, čímž chrání produkci před nedokončenou nebo rozbitou změnou.
CI/CD je jádrem DevOps praxe, protože nahrazuje ruční, chybové kroky
rychlou a konzistentní automatizací.

Kontrolní otázky

1. Jaký je konkrétní rozdíl mezi Continuous Delivery a Continuous
   Deployment?
2. Proč CI klade důraz na časté (ne jednorázové, velké) slučování změn?
3. Co se stane s pipeline, když selže fáze testů, a proč je to žádoucí
   chování?
4. Mini cvičení: nakreslete (textově, jako v příkladu výše) pipeline pro
   projekt, na kterém jste dříve pracovali — rozdělte ji na fáze a
   označte, kde by podle vás mělo být ruční schválení a kde plná
   automatizace.