CI/CD pipeline krok za krokem

Co je CI/CD a proč ho zavést

CI/CD představuje soubor postupů a nástrojů pro automatizaci buildů, testování a nasazování. Cílem je zkrátit „lead time“ od commitu do produkce, zlepšit kvalitu a omezit rizika díky malým, opakovatelným krokům. V praxi to znamená, že každý commit spustí build, testy a statickou analýzu (CI) a ověřený artefakt se automaticky propaguje přes jednotlivá prostředí (CD) až do produkce, s podporou kontrol a případně „gated“ schvalování.

Architektura CI/CD pipeline: stavební bloky

Spouštěče (triggery) – události jako push, pull_request/merge_request, naplánované spouštění (CRON), nebo manuální spuštění.
Fáze – typicky validate → build → test → package → scan → deploy → verify.
Joby – konkrétní kroky jako kompilace, testování, publikace artefaktů.
Artefakty – výstupy buildu, např. balíčky, Docker image, generovaná dokumentace.
Prostředí – sekvence dev → test → staging → production, ideálně co nejvíce izomorfní.
Tajné údaje – přístupové klíče, tokeny, certifikáty uložené v bezpečném trezoru (vault/secrets management).
Audit a telemetrie – logy, metriky, notifikace a trasování událostí.

Předpoklady a příprava repozitáře

Standardizace struktury – kořenové soubory jako README, LICENSE, CONTRIBUTING, CHANGELOG.
Manifest a lockfile – například package.json s package-lock.json, nebo pyproject.toml s poetry.lock a podobně.
Testovací rámec – jednotkové a integrační testy s jasnou příkazovou strukturou (npm test, pytest, mvn test).
Nástroje kvality – lintery (ESLint, Flake8), formátovače (Prettier, Black), statická analýza bezpečnosti (SAST) nástroje jako semgrep, CodeQL.
Konfigurace CI – YAML nebo DSL konfigurační soubory v kořeni repozitáře, např. .github/workflows/ci.yml či .gitlab-ci.yml.

Strategie větvení a verzování

Trunk-based – krátké feature větve, časté slučování do main, využití feature flagů pro nehotové funkce.
GitFlow – oddělené větve develop, release/*, hotfix/*; vhodné pro regulovaná prostředí.
Semantické verzování – ve formátu MAJOR.MINOR.PATCH spolu s generovaným changelogem na základě konvenčních commitů (Conventional Commits).

Krok 1: Validace commitu (pre-commit a CI lint)

Začněte nejrychlejšími kontrolami: formátování, linting, statická analýza a bezpečnostní skeny závislostí. Tyto kroky pomáhají odhalit chyby dříve, než spustíte nákladné buildy a testy.

# Příklad npm skriptů "scripts": { "lint": "eslint src", "format:check": "prettier -c .", "sast": "semgrep --config p/ci", "audit": "npm audit --production" }

Krok 2: Deterministický build

Zajistěte reprodukovatelnost buildu tím, že pevně definujete verze závislostí, použijete cache (např. build cache v CI), princip „build once“ a archivy artefaktů. V případě kontejnerů využijte multi-stage Docker build.

# Multi-stage Dockerfile (Node.js) FROM node:20 AS deps WORKDIR /app COPY package*.json ./ RUN npm ci
FROM node:20 AS build
WORKDIR /app
COPY --from=deps /app/node_modules node_modules
COPY . .
RUN npm run build
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
COPY --from=build /app/dist dist
COPY package*.json .
CMD ["dist/server.js"]

Krok 3: Automatické testování (unit, integration, e2e)

Unit testy – rychlé, izolované testy jednotlivých komponent.
Integrace – testy proti reálným službám nebo v kontejnerech (např. Docker Compose).
End-to-end – testy celého systému proti testovacímu prostředí (Playwright/Cypress), s paralelizací a „shardingem“ testů.

# docker-compose.test.yml (lokální i v CI) services: db: image: postgres:16 environment: POSTGRES_PASSWORD: test app: build: . command: npm run test:integration depends_on: [db]

Krok 4: Bezpečnostní a kvalitativní brány

SAST/Secrets scan – detekce tajných údajů a bezpečnostních zranitelností přímo v kódu.
Dependency scanning – kontrola známých zranitelností (CVE) v používaných verzích knihoven.
DAST – dynamická bezpečnostní analýza běžící aplikace (např. ZAP, automatizace Burp).
Licence compliance – kontrola povolených licencí a generování reportů pro audit.

Krok 5: Artefakty a registry

Build musí vyprodukovat digitálně podepsaný artefakt (balíček, image), který je uložený v repozitáři artefaktů (Nexus, Artifactory, Package Registry) nebo v container registru (GHCR, ECR, GCR). Dbejte na princip build once, deploy many – stejný commit nepřebuildovávejte při propagaci mezi prostředími.

Krok 6: Nasazení do prostředí (CD)

Dev/Test – automatické nasazení po úspěšném dokončení CI.
Staging – automatické nasazení po manuálním schválení (např. manuální job, ochrana prostředí).
Production – řízené nasazení s podporou schvalování a maintenance window, nebo plně automatizované s implementací canary či blue-green deploymentu.

# Výřez z Helm values.yaml pro Kubernetes nasazení image: repository: ghcr.io/org/app tag: "1.4.2" # pevné označení verze artefaktu replicaCount: 3 autoscaling: enabled: true minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 70

Krok 7: Ověření nasazení a rollback

Smoke testy – jednoduché health-checky po nasazení.
Post-deploy testy – e2e testy vůči právě nasazené verzi.
Automatický rollback – spuštění při neúspěchu verifikace nebo zhoršení metrik (např. překročení SLO error budgetu, zvýšení latence nebo chybovosti).

Ukázka: GitHub Actions CI pipeline

name: ci on: push: branches: [ main ] pull_request: jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20, cache: 'npm' } - run: npm ci - run: npm run format:check - run: npm run lint - run: npm run test -- --ci --reporters=jest-junit - name: Upload test report uses: actions/upload-artifact@v4 with: { name: junit, path: junit.xml }
build_and_push_image:
needs: validate
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
id-token: write
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
context: .
push: true
tags: ghcr.io/${{ github.repository }}/app:${{ github.sha }}
cache-from: type=gha
cache-to: type=gha,mode=max

Ukázka: GitLab CI s prostředími a manuálním schválením

stages: [validate, build, deploy]
validate:
stage: validate
image: node:20
script:
- npm ci
- npm run lint
- npm test
artifacts:
when: always
reports:
junit: junit.xml

build:
stage: build
image: gcr.io/kaniko-project/executor:latest
script:
- >/kaniko/.docker/config.json echo '{"credHelpers":{"registry.gitlab.com":"gcloud"}}'
- /kaniko/executor --context $CI_PROJECT_DIR --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
needs: [validate]

deploy_staging:
stage: deploy
environment:
name: staging
url: https://staging.example.com
script:
- helm upgrade --install app chart/ --set image.tag=$CI_COMMIT_SHA
when: manual
needs: [build]

deploy_prod:
stage: deploy
environment:
name: production
url: https://app.example.com
script:
- helm upgrade --install app chart/ --set image.tag=$CI_COMMIT_SHA
when: manual
only:
- tags

Ukázka: Jenkins deklarativní pipeline

pipeline { agent any options { timestamps() } triggers { pollSCM('@daily') } stages { stage('Validate') { steps { sh 'npm ci' sh 'npm run lint' sh 'npm test' } } stage('Build Image') { steps { sh 'docker build -t registry/app:${GIT_COMMIT} .' sh 'docker push registry/app:${GIT_COMMIT}' } } stage('Deploy Staging') { when { branch 'main' } steps { sh 'helm upgrade --install app chart/ --set image.tag=${GIT_COMMIT}' } } } post { always { junit 'junit.xml' } } }

Ukázka: Azure DevOps (YAML)

trigger: branches: { include: [ main ] }
stages:

stage: Validate
jobs:

job: LintTest
pool: { vmImage: 'ubuntu-latest' }
steps:

task: NodeTool@0
inputs: { versionSpec: '20.x' }

script: npm ci && npm run lint && npm test

stage: Build
dependsOn: Validate
jobs:

job: BuildImage
steps:

task: Docker@2
inputs:
command: buildAndPush
repository: org/app
dockerfile: '**/Dockerfile'
tags: $(Build.SourceVersion)

Správa tajných údajů a konfigurací

Správa tajných dat – využijte nativní trezory jako GitHub Secrets, GitLab CI Variables, Azure Key Vault nebo HashiCorp Vault.
Konfigurace per prostředí – oddělte konfiguraci od kódu; doporučuje se využívat ConfigMap/Secret v Kubernetes nebo princip 12-Factor App „config in the environment“.
Rotace a audit – pravidelná výměna klíčů, audit přístupů a „just-in-time“ přidělování práv (například OIDC federace místo statických tokenů).

Nasazovací strategie: blue-green, canary, progressive delivery

Blue-green deployment – dvě identická prostředí; přepnutí směrování provozu (traffic switch) minimalizuje výpadky a zjednodušuje rollback.
Canary release – postupné nasazování do části provozu, např. 1% → 10% → 50% → 100% uživatelů.
Progressive delivery – řízené metrikami (nástroje jako Argo Rollouts, Flagger), automatické zastavení nasazení při regresi.

Feature flagy a dark launching

Oddělte proces releasu od samotného nasazení. Pomocí feature flagů aktivujte funkce pouze pro vybrané podmnožiny uživatelů, usnadněte A/B testování a umožněte bezpečný rollback funkcionality bez nutnosti redeploye.

Observabilita a kontrola kvality po nasazení

Metriky – latence, chybovost, saturace systému podle SRE principu „golden signals“, monitoring SLO a SLI.
Logy a tracing – korelace releasů s událostmi, využití OpenTelemetry pro jednotné sledování tras výkonu a chyb.
Notifikace – integrace CI/CD s nástroji jako Slack nebo Teams pro upozornění na selhání i úspěšné releasy.

Maticové buildy, caching a paralelizace

Zrychlete pipeline pomocí paralelních jobů, maticového testování (různé verze jazyka či operačního systému) a per-job cache (např. ~/.m2, ~/.npm, pip cache). Dbejte na správnou invalidaci cache po změně lockfile.

# GitHub Actions – matice testovací strategie: matrix: node: [18, 20, 22] steps: - uses: actions/setup-node@v4 with: { node-version: ${{ matrix.node }}, cache: 'npm' }

Infrastructure as Code (IaC) v pipeline

Terraform/Ansible – správa cloudových zdrojů s aplikací změn přes schválené plány (plan → review → apply).
GitOps – deklarativní správa stavu clusteru (Argo CD, Flux); pipeline pouze pushuje manifest nebo Helm chart.
Policy as Code – validace konfigurací před aplikací pomocí nástrojů jako OPA, Conftest nebo Kyverno.