Co je CI/CD: od ručního deploy k automatizovaným pipelines

Co je CI/CD: od ručního deploy k automatizovaným pipelines

Téměř každý projekt začíná stejně. Jeden vývojář, jeden server, jeden způsob, jak nasadit změny: připojit se přes SSH, udělat git pull, restartovat službu. Funguje to. Dokud je projekt malý, je to dokonce rychlejší než jakákoli automatizace, protože celý proces zabere minutu a nevyžaduje žádné nastavení.

Problémy nezačínají kvůli velikosti kódu, ale kvůli počtu lidí a četnosti změn. Dva vývojáři už mohou nasadit na server různé verze jednoho souboru. Tři už potřebují dohodu, kdo a kdy deployuje. Za půl roku se v projektu objeví staging prostředí, za další rok — samostatný server pro klientskou demo verzi, a každý nový server je další sada ručních kroků, které si někdo musí pamatovat a provádět bez chyb.

CI/CD je odpověď na tento problém. Místo instrukce v hlavě (nebo v souboru deploy.txt, který nikdo dva roky neaktualizoval) se objevuje kód, který provádí tytéž akce stejně, pokaždé a bez účasti člověka. Tento článek vysvětluje, co přesně se skrývá za zkratkou, z čeho se skládá pipeline a jaké nástroje k tomu v roce 2026 existují.

1.1 Typická situace bez CI/CD

Vypadá to zhruba takto. Vývojář dokončil funkci, zkontroloval ji lokálně, udělal commit a push. Dál otevírá terminál:

ssh deploy@192.0.2.10
cd /var/www/app
git pull origin main
npm ci --production
npm run build
sudo systemctl restart app

Šest příkazů, dvě minuty. Vypadá to bezpečně přesně do chvíle, dokud všechno jde podle scénáře. Ve skutečnosti se mezi těmito řádky skrývá desítka předpokladů: že na serveru je tatáž verze Node.js, že git pull nespadne kvůli lokálním změnám, které tam někdo nechal během nočního incidentu, že build nesežere celou paměť a nepoloží sousední službu, že po restartu se aplikace skutečně zvedla a nespadla do smyčky pádů.

Samostatnou kapitolou je databáze. Migrace se v ručním procesu téměř vždy provádějí samostatným příkazem, na který je snadné zapomenout nebo ho spustit dvakrát. Klasika žánru: kód už vyžaduje nový sloupec, ale migrace ještě není aplikovaná, a aplikace padá na každém požadavku po těch pět minut, než někdo najde v chatu potřebný příkaz.

1.2 Co se kazí

Ruční deploy se láme ve třech směrech, a všechny tři se časem jen zesilují.

Lidský faktor. Není to o nedbalosti, ale o statistice. Jakákoli posloupnost deseti kroků, kterou člověk provádí ručně několikrát týdně, bude dřív nebo později provedena s chybou: nesprávná větev, nesprávný server v druhé záložce terminálu, zapomenutý krok se sestavením frontendu, migrace aplikovaná na produkční databázi místo staging. Čím zkušenější inženýr, tím vzácněji se to stává, ale nikdy to nezmizí úplně.

Nesynchronizovaná prostředí. Lokální stroj vývojáře, staging a produkce se téměř vždy liší: verzí interpretu, verzí systémových knihoven, sadou proměnných prostředí, přítomností cache. Věta „u mě lokálně to funguje“ není výmluva, ale přesný popis situace, kdy kód skutečně funguje v jednom prostředí a nefunguje v jiném. Bez automatizace nikdo neví, jak přesně se tato tři prostředí rozešla, protože je nikdo nikdy systematicky nesrovnával.

Strach z deploy. To je nejdražší důsledek a nejméně nápadný. Pokud je nasazení změn riskantní a dělá se ručně, tým začíná nasazovat vzácněji. Místo deseti malých změn týdně se objevuje jeden velký release jednou za dva týdny. Je v něm stovky změněných souborů, a když se po něm něco rozbije, nikdo nedokáže rychle říct, který commit je vinen. Riziko release roste, proto se release dělají ještě vzácněji, a cyklus se uzavírá. Páteční „pojďme až v pondělí“ je symptom právě tohoto problému.

2. CI a CD: v čem je rozdíl

Zkratka CI/CD spojuje tři různé praktiky, a zmatek kolem ní vzniká proto, že písmeno D znamená hned dva různé pojmy. Rozebereme je zvlášť.

2.1 CI — Continuous Integration

Continuous Integration je praktika, při které se kód každého vývojáře automaticky sestavuje a kontroluje při každém odeslání do repozitáře. Klíčové slovo je zde integrace: myšlenka je v tom slévat změny do společné větve často (denně nebo častěji) a hned kontrolovat, že společný kód zůstává funkční.

Typický CI proces se spouští na každý push a na každý pull request a uvnitř dělá zhruba toto:

• Sestavuje projekt. Kompilace, instalace závislostí, sestavení frontendu, sestavení Docker image. Pokud build padá, nemá smysl jít dál.
• Prohání lintery a statickou analýzu. Formátování, nepoužité proměnné, potenciální chyby typů, porušení stylu kódu.
• Provádí testy. Jednotkové testy téměř vždy, integrační pokud existují, někdy e2e testy v prohlížeči.
• Kontroluje závislosti na zranitelnosti. npm audit, pip-audit, Trivy pro image, skenování secrets v kódu.

Výsledkem CI je odpověď ano/ne na otázku „lze tyto změny slít“. V GitHubu a GitLabu se tato odpověď mění na zelenou nebo červenou značku vedle commitu a na zablokování sloučení pull requestu, dokud kontroly neprojdou.

Důležitý detail: CI nedeployuje nic a nikam. Jeho zóna odpovědnosti končí tam, kde je kód uznán za způsobilý.

2.2 CD — Continuous Delivery

Continuous Delivery je pokračování CI: po úspěšných kontrolách systém automaticky připravuje release a dovádí ho do stavu „lze nasadit kdykoli“. Prakticky to znamená:

• sestavený artefakt (Docker image, balíček .deb, archiv se statikou) je uložen do úložiště a označen verzí;
• artefakt je automaticky nasazen na staging prostředí;
• na staging jsou prohnány integrační a akceptační testy;
• tlačítko „nasadit na produkci“ je dostupné, ale mačká ho člověk.

Ruční krok zde není nedostatek, ale vědomé rozhodnutí. Je potřebný tam, kde se nasazení má shodovat s obchodními událostmi (marketingová kampaň, dohodnuté servisní okno, release mobilní aplikace ve storu) nebo kde regulatorní požadavky předpokládají potvrzení od odpovědné osoby.

2.3 CD — Continuous Deployment

Continuous Deployment odstraňuje poslední ruční krok. Každá změna, která prošla všemi kontrolami, se automaticky dostává na produkci bez účasti člověka. Člověk mačká tlačítko přesně jednou: když slévá pull request.

To je nejzralejší úroveň a vyžaduje infrastrukturu, která si problému všimne místo člověka:

• Spolehlivé pokrytí testy. Pokud testy nechytají regrese, automatický deploy jen rychleji doručuje rozbitý kód klientům.
• Feature flags. Nedokončená funkce jede na produkci vypnutá a zapíná se zvlášť, už bez deploy.
• Postupné nasazení. Canary nebo blue-green: nová verze nejdřív dostává část provozu, a teprve potom celý.
• Monitoring a automatický rollback. Pokud po nasazení vzrostl podíl chyb nebo latence odpovědi, systém vrací předchozí verzi sám.

2.4 Schéma: kód → CI → CD → produkce

Řetězec od commitu k produkci vypadá takto:

push do větve
   ↓
[CI]  build → lint → test → security scan
   ↓  (všechno zelené)
[CD]  sestavení artefaktu → úložiště → deploy na staging → testy na staging
   ↓
Continuous Delivery: čeká na ruční potvrzení
Continuous Deployment: jede dál samostatně
   ↓
produkce + monitoring + možnost rollback

Rozdíl mezi třemi praktikami se scvrkává na to, kde končí automatika:

Praktická rada: pohybujte se po této tabulce shora dolů a nepřeskakujte řádky. CI přináší užitek hned a téměř bez rizika. Continuous Delivery vyžaduje několik týdnů na nastavení staging a úložiště. Continuous Deployment má smysl tehdy, když tým už několik měsíců žije s Delivery a vidí, že ruční krok se stal formalitou.

3. Co se děje uvnitř pipeline

Pipeline je popis celého procesu ve formě souboru v repozitáři: .github/workflows/ci.yml pro GitHub Actions, .gitlab-ci.yml pro GitLab CI. Terminologie se u různých systémů liší v detailech, ale stavební bloky jsou všude stejné: trigger, fáze, úloha, artefakt.

3.1 Trigger: událost, která spouští pipeline

Trigger odpovídá na otázku „kdy“. Nejrozšířenější varianty:

• push do určité větve. Základní trigger pro CI.
• pull request / merge request. Kontroluje výsledek sloučení ještě předtím, než k němu došlo.
• tag. Vytvoření tagu v1.4.0 spouští release: sestavení artefaktu, publikaci, deploy.
• cron / schedule. Noční průchody těžkých testů, denní skenování závislostí na nové CVE.
• ruční spuštění. workflow_dispatch v GitHubu, tlačítko Run pipeline v GitLabu. Právě tento trigger realizuje ruční krok v Continuous Delivery.
• externí událost. Volání přes API nebo webhook: například pipeline v sousedním repozitáři, která sestavila novou verzi knihovny.

Zvlášť stojí za to vědět o filtru podle cest. V monorepozitáři nemá smysl prohánět testy backendu, když se změnil jen soubor dokumentace:

# GitHub Actions
on:
  push:
    branches: [main]
    paths:
      - 'backend/**'
      - '!**.md'

3.2 Stage: logická skupina kroků

Fáze odpovídá na otázku „v jakém pořadí“. Klasická sada je build → test → deploy, a smysl rozdělení je v tom, že další fáze startuje jen tehdy, když předchozí zcela úspěšně skončila. Nemá smysl deployovat to, co se nesestavilo, a testovat to, co se nesestavilo, také.

Fáze dávají ještě jednu užitečnou vlastnost: všechno uvnitř jedné fáze se může provádět paralelně. Pokud jsou ve fázi test jednotkové testy, linter a skener zranitelností, spouštějí se současně na různých runnerech, a fáze trvá tolik, kolik nejpomalejší ze tří kontrol, a ne tolik, kolik je jejich součet.

3.3 Job: konkrétní úloha

Úloha je to, co se reálně provádí: sada příkazů v konkrétním prostředí na konkrétním runneru. Každá úloha startuje v čistém prostředí, proto vždy začíná získáním kódu a instalací závislostí.

Minimální funkční příklad pro GitHub Actions:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test

Tentýž smysl v syntaxi GitLab CI:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  image: node:20
  script:
    - npm test

deploy:
  stage: deploy
  script:
    - ./scripts/deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

V GitHub Actions fáze jako samostatná entita nejsou, pořadí se zadává závislostmi přes klíč needs. V GitLabu needs také existuje a funguje nad fázemi, což dovoluje stavět graf závislostí místo přísné fronty. U velkých pipeline to znatelně zkracuje celkový čas.

3.4 Artifact: soubor, který se předává mezi úlohami

Každá úloha pracuje ve vlastním čistém prostředí, proto výsledek práce jedné úlohy není druhé automaticky vidět. Artefakty jsou mechanismus předávání: fáze sestavení ukládá hotové soubory do úložiště, fáze deploy si je odtud bere.

Typické artefakty: sestavený frontend, zkompilovaný binárník, vygenerovaný balíček, a také reporty (výsledky testů, pokrytí kódu, report skeneru zranitelností), na které je pohodlné se dívat přímo v rozhraní CI.

Artefakty je snadné splést s cache, i když jejich úlohy jsou různé:

4. Co CI/CD dává v praxi

Abstraktní užitek z automatizace je jasný každému. Užitečnější je podívat se, co přesně se mění v každodenní práci.

4.1 Rychlý feedback

Hlavní hodnota CI není v úspoře času na spuštění testů, ale ve zmenšení intervalu mezi chybou a jejím odhalením. Cena opravy přímo závisí na tomto intervalu.

Vedlejší efekt rychlého feedbacku je příjemnější než zřejmá úspora: vývojáři začínají dělat menší commity. Když kontrola zabere dvě minuty, není důvod hromadit změny. A menší commity znamenají jednodušší review a přesnější odpověď na otázku „po které změně se to rozbilo“.

4.2 Stejné podmínky ve všech prostředích

Pipeline se provádí v popsaném prostředí: konkrétní image, konkrétní verze interpretu, závislosti z lock souboru. Toto prostředí je popsáno v repozitáři vedle kódu, proto je stejné pro všechny a mění se jen přes pull request.

Důsledky toho přesahují rámec samotného buildu:

• Aktualizace verzí se stává řiditelnou. Přechod z Node.js 20 na 22 je jeden řádek v konfigu, a pipeline hned ukazuje, co přesně se rozbije.
• Onboarding se zjednodušuje. Nový vývojář čte konfig pipeline a vidí přesný seznam toho, co projekt potřebuje.
• Produkce přestává být unikátním serverem. Pokud je deploy nasazením téhož image, který prošel testy, rozdíl mezi prostředími se scvrkává na konfiguraci a data.

4.3 Deploy se stává rutinou, a ne událostí

Když je nasazení jedna akce, která se provádí stejně a má předvídatelné vrácení, mění se sama kultura práce. Místo dvoutýdenních release se objevují denní, a každý z nich obsahuje málo změn, proto je riziko každého jednotlivého release nevelké.

Funguje to i opačným směrem: když je nasazení levné, tým ochotněji nasazuje malá vylepšení, která se dřív odkládala na „další velký release“. Oprava textu chyby, drobná optimalizace dotazu, aktualizace závislosti přestávají čekat na svou řadu.

5. Populární nástroje

Trh CI/CD se dělí na tři skupiny: cloudové platformy zabudované do git hostingu; self-hosted git platformy s vlastním CI; samostatné CI systémy, které fungují s jakýmkoli repozitářem.

5.1 Cloudové platformy

• GitHub Actions. Spuštěn v roce 2019, teď nejrozšířenější varianta díky obrovskému marketplace hotových akcí a tomu, že většina open source projektů žije na GitHubu. Konfig v .github/workflows/, bezplatné minuty pro veřejné repozitáře, omezená kvóta pro privátní.
• GitLab CI. Zabudovaný do GitLabu od roku 2015 a historicky silnější v části složitých pipeline: fáze, graf závislostí, dceřiné pipeline, zabudovaná prostředí s historií deploy. Konfig v .gitlab-ci.yml. Dostupný jak v cloudu, tak ve vlastní instalaci.
• Bitbucket Pipelines. Logická volba pro týmy, které už pracují v ekosystému Atlassian spolu s Jirou. Jednodušší než konkurenti, s těsnější integrací s úlohami.
• CircleCI. Nezávislá platforma s reputací rychlé: flexibilní nastavení zdrojů pod úlohu, znovupoužitelné konfigurace (orbs), rozvinutá cache. Připojuje se ke GitHubu, GitLabu a Bitbucketu.

Společný rys této skupiny: nic není třeba administrovat, platba za využité minuty nebo podle tarifního plánu. Společné omezení: kvóty, omezené zdroje na standardních runnerech a to, že váš kód se sestavuje na cizí infrastruktuře.

5.2 Self-hosted Git se zabudovaným CI

• Gitea. Lehká git platforma v Go, která zabírá desítky megabajtů paměti a spouští se jedním binárníkem. Od verze 1.19 má zabudované CI (Gitea Actions), kompatibilní se syntaxí GitHub Actions: většina jednoduchých workflow se přenáší téměř bez úprav.
• Forgejo. Fork Gitea pod vedením komunity, s týmž mechanismem Actions. Vybírají si ho ti, pro koho je důležitý model řízení projektu a plně svobodná licence.
• Gogs. Předchůdce Gitea, ještě lehčí a ještě jednodušší, ale bez zabudovaného CI. Používá se tam, kde je potřeba minimální git hosting, a CI se připojuje zvlášť.

Tato skupina má smysl, když kód nesmí opustit vaši infrastrukturu: požadavky zákazníka, regulatorní omezení, práce v uzavřeném okruhu. Cena otázky je vlastní administrace: zálohy, aktualizace, dostupnost.

5.3 Samostatné CI systémy

• Jenkins. Veterán oboru od roku 2011, s tisíci pluginů a schopností integrovat se prakticky s čímkoli. Platí za to složitostí: vlastní jazyk popisů pipeline, znatelné náklady na podporu, pravidelné aktualizace pluginů. Dodnes rozšířený ve velkých firmách s nahromaděnou automatizací.
• Drone CI. Kontejnerový CI systém s jednoduchým YAML: každý krok je spuštění kontejneru. Lehký a srozumitelný, ale po přechodu pod Harness se změnily licenční podmínky, což stojí za to zohlednit při výběru.
• Woodpecker CI. Fork Drone pod svobodnou licencí, který rozvíjí komunita. Zachovává jednoduchost originálu a dobře funguje v páru s Gitea nebo Forgejo, proto je to populární volba pro plně self-hosted stack.

5.4 Porovnání a volba pro sérii

V dalších článcích série se zaměříme na GitHub Actions a GitLab CI, a důvod je čistě praktický. Za prvé, jsou to nejširší ekosystémy: téměř jakákoli úloha už má hotový příklad. Za druhé, obě platformy dovolují připojit vlastní runner na vašem serveru, aniž byste zvedali vlastní git platformu. Tedy kód může zůstat ve zvyklém GitHubu nebo GitLabu, a build a deploy se budou provádět na vašem železe, s vašimi zdroji a vašimi pravidly přístupu k produkci.

Syntaxe Gitea Actions téměř opakuje GitHub Actions, proto všechno napsané v sérii o workflow bude použitelné i tam, s opravou na absenci části hotových akcí z marketplace.

6. Závěr

CI/CD není samostatný nástroj, který se instaluje, ale způsob, jak popsat proces doručování kódu ve formě kódu. Tři praktiky za zkratkou se liší tím, jak daleko sahá automatika:

• Continuous Integration kontroluje každou změnu automaticky a dává odpověď za minuty místo dnů. To je nejlevnější krok s největší návratností, a začínat stojí za to právě jím.
• Continuous Delivery dovádí zkontrolovanou změnu do stavu hotového release a nasazuje ji na staging, přičemž rozhodnutí o produkci nechává člověku.
• Continuous Deployment odstraňuje i toto rozhodnutí, ale vyžaduje zralé testy, pozorovatelnost a mechanismus vrácení.

Jakákoli pipeline se skládá z týchž bloků: trigger určuje, kdy se spustit, fáze zadávají pořadí, úlohy vykonávají práci, artefakty předávají výsledky dál. Se znalostí těchto čtyř pojmů lze číst konfig jakéhokoli CI systému, i když syntaxi vidíte poprvé.

Praktický výsledek je také měřitelný: chyby se nacházejí za minuty, prostředí se přestávají rozcházet, a nasazení se z události mění na rutinu, kterou dělají denně a bez porad.

Co dál v sérii

V druhé části rozebereme architekturu self-hosted runneru: jak je uspořádán agent, který provádí vaše úlohy, proč stojí za to vynést ho na vlastní server (zdroje, přístup do uzavřené sítě, cache, cena při velkém objemu buildů), jak ho nainstalovat pro GitHub Actions a GitLab CI, a hlavně jak izolovat provádění cizího kódu, aby se runner nestal nejslabším bodem vaší infrastruktury.

Časté otázky