CI/CD pipeline0

CI/CD pipeline krok za krokem

By Natália ŠimkováPosted on
Time to Read:-words
CI/CD pipeline krok za krokem

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

CI/CD je soubor postupů a nástrojů pro automatizaci buildů, testů a nasazení. Cílem je zkrátit „lead time“ od commitu po produkci, 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é 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), build-once princip a artefakt archivy. 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.
# 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 proti nasazené verzi.
  • Automatický rollback – při neúspěchu verifikace nebo zhoršení metrik (SLO error budget, latency, error rate).

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 zjednodušuje rollback.
  • Canary – postupné pouště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ů, povolte A/B testy a bezpečný rollback na úrovni funkcionality bez 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 per-job cache (např. ~/.m2, ~/.npm, pip cache). 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 cloud zdrojů, apply přes schválené plány (plan → review → apply).
  • GitOps – deklarativní stav clustru (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ů.

Kontinuální zlepšování a měření (DORA metriky)

  • Deployment frequency – jak často nasazujete.
  • Lead time for changes – doba od commitu po nasazení.
  • Change failure rate – % releasů vyžadujících zásah/rollback.
  • MTTR – průměrná doba obnovení služby.

CI/CD pipeline pravidelně revidujte: vyhodnocení flakiness testů, optimalizace kroků, odstranění duplicit, sledování nákladů (runtime minut, storage artefaktů).

Typické anti-patterny a jak se jim vyhnout

  • Monolitická pipeline – vše v jednom jobu; rozdělte na fáze a paralelizujte.
  • Nedeterministické buildy – chybějící lockfile, proměnlivé základní image.
  • Rebuild při propagaci – porušení „build once“; nasazujte stejný artefakt.
  • Tajné údaje v proměnných prostředí bez omezení – použijte trezor a krátkodobé tokeny.
  • Flaky testy – izolujte, revidujte a stabilizujte; dočasně používejte retry s limitem.

Kompletní „end-to-end“ příklad (shrnutí kroků)

# 1) CI: validate → build → test → scan → publish # 2) CD: deploy dev → staging (manual approval) → prod (canary) # 3) Observabilita: smoke test + rollback při degradaci SLO

Závěr

CI/CD pipeline je běžící produkt, ne jednorázový projekt. Začněte jednoduchou validací a buildem, přidejte testy a bezpečnostní skeny, zaveďte artefakt registry a automatizované nasazování s postupnou verifikací. S růstem týmu doplňujte GitOps, progressive delivery a politiku bezpečného supply chainu. Cílem je krátký a spolehlivý tok změn od vývojáře k uživateli – měřený a průběžně zlepšovaný.

Poradňa

Potrebujete radu? Chcete pridať komentár, doplniť alebo upraviť túto stránku? Vyplňte textové pole nižšie. Ďakujeme ♥