Vytvoření CI/CD pipeline krok za krokem: automatizace procesu

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

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

Architektura CI/CD pipeline: stavební bloky

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

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

Standardizace struktury – kořenové README, LICENSE, CONTRIBUTING, CHANGELOG.
Manifest a lockfile – package.json + package-lock.json, pyproject.toml + poetry.lock apod.
Testovací rámec – jednotkové a integrační testy s jasnými příkazy (npm test, pytest, mvn test).
Nástroje kvality – lintery (ESLint, Flake8), formátovače (Prettier, Black), SAST (semgrep, CodeQL).
Konfigurace CI – YAML/DSL soubory v kořeni, např. .github/workflows/ci.yml či .gitlab-ci.yml.

Strategie větvení a verzování

Trunk-based – krátké feature větve, časté merge do main, feature flagy pro nehotové funkce.
GitFlow – oddělené větve develop, release/*, hotfix/*; vhodné pro regulované prostředí.
Semantické verzování – MAJOR.MINOR.PATCH + generovaný changelog z 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 zachytí 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

Zaručte reprodukovatelnost: definujte přesné verze závislostí, používejte cache (např. build cache v CI), princip build-once a archivaci artefaktů. V kontejnerech 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 – rychlé, izolované.
Integration – proti reálným službám nebo kontejnerům (Docker Compose).
End-to-end – proti testovacímu prostředí (Playwright/Cypress), paralelizace a „sharding“ testů.

# docker-compose.test.yml (lokální/in 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 – hledání tajemství a zranitelností v kódu.
Dependency scanning – kontrola CVE ve verzích.
DAST – dynamické skeny běžící aplikace (ZAP, Burp automatizace).
Licence compliance – povolené licence, reporty pro audit.

Krok 5: Artefakty a registry

Build by měl vyprodukovat artefakt (balíček, image), který je podepsaný a uložený v repozitáři artefaktů (Nexus/Artifactory/Package Registry) nebo v container registru (GHCR/ECR/GCR). Nepřebuildovávejte stejný commit při propagaci – build once, deploy many.

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

Dev/Test – automatické nasazení po úspěšném CI.
Staging – automatické po schválení (manual job, environment protection).
Production – řízené (schvalování, maintenance window) nebo plně automatické s canary/blue-green strategií.

# Kubernetes nasazení (Helm values.yaml – výřez)  
image:  
  repository: ghcr.io/org/app  
  tag: "1.4.2" # pin na verzi artefaktu  
replicaCount: 3  
autoscaling:  
  enabled: true  
  minReplicas: 3  
  maxReplicas: 10  
  targetCPUUtilizationPercentage: 70

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

Smoke testy – syntetické health-checky po deploy.
Post-deploy testy – e2e testy proti nasazené verzi.
Automatický rollback – při neúspěchu verifikace nebo zhoršení metrik (SLO error budget, latence, chybovost).

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í

Secrets management – nativní trezory (GitHub Secrets, GitLab CI Variables, Azure Key Vault) či HashiCorp Vault.
Konfigurace per prostředí – oddělte konfiguraci od kódu; používejte ConfigMap/Secret v Kubernetes, 12-Factor „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 (OIDC federace místo statických tokenů).

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

Blue-green – dvě identická prostředí; přepnutí směrování provozu (switch) minimalizuje výpadek a usnadňuje rollback.
Canary – postupné uvolňování části provozu na novou verzi (např. 1 % → 10 % → 50 % → 100 %).
Progressive delivery – řízené metrikami (Argo Rollouts/Flagger), automatické zastavení při regresi.

Feature flagy a dark launching

Oddělte releasy od nasazení. Pomocí feature flagů aktivujte funkce pro podmnožiny uživatelů, umožněte A/B testování a bezpečný rollback na úrovni funkcionality bez nutnosti redeploye.

Observabilita a kontrola kvality po deployi

Metriky – latence, chybovost, saturace (SRE „golden signals“), SLO/SLI hlídání.
Logy a tracing – korelace releasů s událostmi; OpenTelemetry pro jednotné trasování.
Notifikace – CI/CD integrace se Slack/Teams; upozornění na selhání i úspěšné releasy.

Maticové buildy, caching a paralelizace

Zrychlete pipeline pomocí paralelních jobů, matic (více verzí jazyka/OS) a cache per job (např. ~/.m2, ~/.npm, pip cache). Dávejte pozor na invalidaci cache při změně lockfile.

# GitHub Actions – matrix test strategy:  
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ů, apply přes schválené plány (plan → review → apply).
GitOps – deklarativní stav clusteru (Argo CD/Flux), pipeline pouze pushuje manifest/Helm chart.
Policy as Code – OPA/Conftest/Kyverno validují konfigurace před aplikací.

Bezpečnost CI/CD

Princip minimálních práv – oddělené identity pro build a deploy, časově omezené tokeny, OIDC federace.
Supply chain – podpis artefaktů (Sigstore/cosign), SBOM (Syft), ověřování při deploy (policy).
Izolace runnerů – self-hosted běžící v sandboxu, neprivilegované kontejnery, omezení síťových přístupů.