Fossil/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
95d1839f0535370deb9027aadd4ad89798b86c92
knowledge-base/CICD.md
Stanislav Hubacek 95d1839f05 First batch
2026-06-11 15:27:28 +02:00

25 KiB
Raw Blame History

🔄 CI/CD a DevOps

CI/CD Pipeline

Code Commit → Build → Test → Package → Deploy to Staging → Integration Tests → Deploy to Production

Detailní pipeline stages

1. Checkout ──→ 2. Lint ──→ 3. Test ──→ 4. Build ──→ 5. Scan ──→ 6. Publish ──→ 7. Deploy
                   │            │                      │
              ESLint/     Unit/Integ/           SAST/SCA/
              Prettier    e2e tests             Container scan
Stage Nástroje Co se děje
Checkout git clone, fetch Stažení kódu z repozitáře, včetně submodulů
Lint ESLint, Prettier, RuboCop, golangci-lint Statická analýza kódu, formátování
Test (unit) Jest, pytest, JUnit Rychlé testy (ms až s), bez závislostí
Test (integration) Testcontainers, Docker Compose Testy s DB, message queue, externí služby
Test (e2e) Playwright, Cypress, Selenium Full-stack testy v prohlížeči
Build Docker build, go build, npm build, Maven Kompilace, sestavení artifactu
Scan (SAST) Semgrep, SonarQube, CodeQL Statická analýza bezpečnosti
Scan (DAST) OWASP ZAP, Burp Suite Dynamická analýza (běžící aplikace)
Scan (SCA) Dependabot, Snyk, Trivy Analýza závislostí a CVE
Publish Docker push, npm publish, Maven deploy Nahrání artifactu do registru
Deploy ArgoCD, Terraform, Helm, kubectl Nasazení do cílového prostředí

Continuous Integration (CI)

  • Automatické sestavení a testy při každém commitu
  • Rychlá feedback smyčka (< 10 min)
  • Linting, type checking, unit testy, security scan (SAST)

Continuous Delivery (CD)

  • Automatické deploye do staging / test prostředí
  • Ruční schválení do produkce (optional)
  • Smoke testy po deployi

Continuous Deployment

  • Plně automatický deploy do produkce
  • Vyžaduje vysokou důvěru v testy a monitoring
  • Feature flagy pro řízení rizika

GitHub Actions detail

Workflow syntax

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: "22"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Matrix builds

  • Spouští stejné joby s různými parametry (OS, jazyková verze, architektura)
  • strategy.matrix — kombinace parametrů (kartézský součin)
  • strategy.fail-fast — zastavení všech při selhání jednoho

Reusable workflows

# .github/workflows/deploy.yml (called)
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      cloud_role:
        required: true

# Volání v caller workflow
jobs:
  deploy:
    uses: ./.github/workflows/deploy.yml
    with:
      environment: staging
    secrets:
      cloud_role: ${{ secrets.STAGING_ROLE }}

Composite actions

  • Vlastní akce bez nutnosti samostatného repozitáře
  • Kombinace run, uses, shell kroků
  • Use case: standardizace lint/test/build napříč repozitáři

Self-hosted runners

  • Vlastní infrastruktura pro běh GitHub Actions
  • Use case: privátní síť, GPU, specifický HW, compliance
  • Škálování: actions-runner-controller (Kubernetes), auto-scaling groups
  • Bezpečnost: izolace jobů, ephemeral runners

GitLab CI detail

stages:
  - lint
  - test
  - build
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

lint:
  stage: lint
  image: node:22
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  image: node:22
  needs: ["lint"]
  script:
    - npm test
  artifacts:
    paths:
      - coverage/
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

deploy-staging:
  stage: deploy
  needs: ["build"]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - kubectl set image deployment/app app=$DOCKER_IMAGE

Koncepty:

  • Stages — sekvenční fáze (každá stage může mít více jobů paralelně)
  • Rules — podmínky spuštění (branch, tag, changes, variables) — nahrazuje only/except
  • Needs — DAG závislosti (job nemusí čekat na celou stage)
  • Artifacts — předávání souborů mezi joby (binárky, reporty, cache)
  • Environments — sledování deployů (rollback, history, approvals)

DAG pipelines (needs)

lint ──→ test ──→ build ──→ deploy-staging ──→ deploy-prod
                        ↓
                   build-arm ──→ test-arm
  • Definuje závislosti mezi joby (ne nutně stages)
  • Umožňuje paralelizaci nezávislých jobů
  • Snižuje celkový čas pipeline

Infrastructure as Code (IaC)

Nástroj Typ Jazyk
Terraform Declarative HCL
OpenTofu Declarative HCL (fork Terraformu)
Pulumi Declarative TypeScript, Python, Go, C#
AWS CDK Declarative TypeScript, Python, Java, C#
CloudFormation Declarative YAML/JSON (AWS)
Azure ARM/Bicep Declarative Bicep, JSON
Ansible Imperative/Config YAML
Chef/Puppet Config mgmt Ruby DSL

Infrastructure as Code (2. vydání) — Kief Morris

Klíčová reference pro navrhování a provozování dynamické cloudové infrastruktury pomocí IaC. Kniha je tool-agnostic — zaměřuje se na vzory a postupy, ne na konkrétní nástroje.

Tři základní praktiky

Praktika Popis
Define everything as code Veškerá infrastruktura definovaná v kódu, version control, repeatabilita
Continuously test and deliver Každá změna prochází pipeline s automatickými testy
Small, independent pieces Malé, volně provázané komponenty — snadnější změna a testování

Principy cloudové infrastruktury

  • Systems reproducible — infrastructure can be recreated from code at any time
  • Systems disposable — instance mohou být zničeny a znovu vytvořeny
  • Systems consistent — všechny prostředí identická (žádné snowflake servery)
  • Processes repeatable — automatizace namísto manuálních postupů
  • Design always changing — infrastruktura se neustále vyvíjí (není build-and-forget)

Anti-vzory (pitfalls)

Anti-vzor Popis
Snowflake server Každý server jiný, nelze reprodukovat
Configuration drift Ruční změny → odchylky od definovaného stavu
Server sprawl Příliš mnoho serverů bez správy
Fragile infrastructure Křehká infrastruktura — změny často rozbijí systém
Automation fear Strach z automatizace → ruční zásahy

Struktura knihy (4 části)

  1. Foundations — rámec nástrojů a technologií pro cloud platformy
  2. Working with infrastructure stacks — definice, provisionování, testování a CD změn infrastruktury
  3. Working with servers and application runtime platforms — provisionování a konfigurace serverů a clusterů
  4. Working with large systems and teams — workflow, governance, architektonické vzory pro více týmů

Organizace IaC kódu

Vzor Popis
Monorepo Jeden repozitář pro vše — build-time integrace, vhodný pro malé týmy
Microrepo Samostatný repozitář pro každý projekt — izolace, vhodný pro velké týmy
Domain organization Organizace kódu podle doménových konceptů (ne podle technologií)

Doporučení:

  • Infrastruktura a aplikace mohou být ve stejném nebo odděleném repozitáři záleží na organizační struktuře (Team Topologies)
  • Konfigurační soubory per-environment (test, staging, production) ukládat v rámci projektu
  • Testy patří k projektu, integrační testy mohou být v samostatném projektu
  • Infrastrukturní kód by neměl přímo deployovat aplikace — použít OS packaging (RPM, deb)

Expand-Contract pattern pro změny infrastruktury

Stejný princip jako u databázových migrací:

  1. Expand — přidat nový resource (nestará verze stále běží)
  2. Migrate — přesunout traffic / závislosti na nový resource
  3. Contract — odstranit starý resource

Zabraňuje výpadkům při refaktorování infrastruktury.

Terraform detail

State locking mechanism

Backend Locking mechanism Poznámka
S3 + DynamoDB DynamoDB (ConditionalPut) Nejčastější, levný, jednoduchý
Terraform Cloud Built-in (API) SaaS, audit logy, VCS integration
Azure Storage Azure Blob Lease Podobný S3 modelu
GCS Cloud Storage Object Hold Omezené
Consul Consul KV session_lock High-availability
PostgreSQL pg_advisory_lock / row lock Vlastní backend

State backends comparison

Vlastnost S3 + DynamoDB Terraform Cloud Consul
Cena $ (S3 + DynamoDB) $$ (free tier omezený) $$ (infra)
Team workflow GitHub Actions + OIDC Native RBAC, runs Vlastní
Locking DynamoDB Built-in Consul session
History S3 versioning Full history, diff None
Remote ops Ne (pouze state) Ano (remote runs) Ne
Encryption SSE-S3/KMS At rest + in transit TLS

Workspaces vs Terragrunt

Aspekt Terraform Workspaces Terragrunt
Separace stavu Jeden backend, klíč: env:/workspace Samostatný backend per env
Code reuse Stejný kód, jiné proměnné DRY konfigurace, moduly
Riziko Omylem apply do špatného workspace Izolované backends
Kdy použít Jednoduché projekty, <5 env Mikroservice, multi-env, multi-team
Extra features — Dependency, include, before_hook

Provider versioning

terraform {
  required_version = ">= 1.5, < 2.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.23"
    }
  }
}
  • ~> 5.0 — pouze patch verze (5.x, x ≥ 0)
  • >= 2.23, < 3.0 — jakákoli 2.x od 2.23
  • ~> constraints zabraňují breaking changes v major/minor

Terraform workflow

terraform init     → Stáhne provider moduly
terraform plan     → Zobrazí změny
terraform apply    → Aplikuje změny
terraform destroy  → Zničí infrastrukturu
terraform validate → Validace syntaxe
terraform fmt     → Formátování HCL

State management

  • Remote state (S3, Terraform Cloud, Azure Storage)
  • State locking (DynamoDB, Consul)
  • Workspaces pro oddělení prostředí

Terraform: Up and Running (3rd ed.) — Yevgeniy Brikman

Praktický průvodce Terraformem od zakladatele Gruntwork. 3. vydání (2022) přidává přes 100 stran nového obsahu, aktualizaci z Terraform 0.12 na 1.2 a dvě nové kapitoly.

Co je nového ve 3. vydání

Novinka Popis
Kapitola: Secrets management Správa tajemství s Terraformem — Vault, AWS Secrets Manager, KMS, OIDC, sensitive proměnné
Kapitola: Multiple providers Práce s vícero regiony, účty, cloudy včetně Kubernetes (AWS EKS)
Terraform 1.0+ Backward compatibility promise, stabilita, HashiCorp IPO
Provider versioning required_providers blok + terraform.lock.hcl (lock file)
Module iteration count a for_each na modulech (od Terraform 0.13)
Variable validation validation {} bloky, precondition / postcondition
Refactoring moved bloky — bezpečný refactoring bez ruční manipulace se state
CI/CD security OIDC autentizace, isolated workers pro terraform apply

Secrets management s Terraformem

# Proměnná označená jako sensitive — nikdy se nezobrazí v logu
variable "db_password" {
  type      = string
  sensitive = true
}

# Čtení secrets z AWS Secrets Manager
data "aws_secretsmanager_secret" "db" {
  name = "production/db/master"
}

data "aws_secretsmanager_secret_version" "db" {
  secret_id = data.aws_secretsmanager_secret.db.id
}

Doporučená hierarchie bezpečnosti:

  1. OIDC — nejbezpečnější, bez creds na CI serveru (GitHub Actions → IAM role)
  2. IAM role — instance profile (EC2, ECS, EKS)
  3. Environment variables — omezené, riziko úniku v logu
  4. Isolated workers — oddělený worker s admin permissions, API pouze plan/apply

Testing Terraform kódu

Vrstva Nástroje Popis
Static analysis terraform validate, tflint, tfsec, checkov Analýza kódu bez běhu
Plan testing conftest + OPA (Rego), terraform plan parse Validace plánu proti policy
Unit tests Terratest (Go), terraform fmt, terraform validate Testování modulů izolovaně
Integration tests Terratest (Go) Skutečné provisionování + assert
End-to-end tests Terratest Plný stack, smoke testy

Policy enforcement

# OPA / conftest — zakázat veřejné S3 bucket
package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  resource.change.after.acl == "public-read"
  msg = sprintf("%s must not be public", [resource.address])
}

Production-grade checklist dle Brikmana

  1. Small modules — jeden modul = jedna věc (single responsibility)
  2. Composable modules — moduly se dají skládat do větších celků
  3. Testable modules — každý modul má testy (Terratest)
  4. Releasable modules — verzování (Git tagy, Terraform Registry)
  5. Version control — všechno v gitu, včetně .terraform.lock.hcl
  6. Remote state — S3 + DynamoDB nebo Terraform Cloud
  7. CI/CD pipeline — plan na MR, apply po merge do main
  8. Secrets management — žádné secrets v plaintextu v kódu
  9. Policy as code — OPA / Sentinel pro compliance
  10. Sandbox prostředí — každý vývojář má vlastní izolované prostředí

Zlaté pravidlo (Golden Rule of Terraform)

Master branch state musí být vždy v souladu s produkčním prostředím. Nikdy nespouštět terraform apply ručně lokálně na produkci — vždy přes CI/CD.

Dockerfile best practices

# Multi-stage build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# Runtime stage — distroless
FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER nonroot:nonroot
EXPOSE 3000
CMD ["dist/server.js"]

Pravidla:

  • Multi-stage build — oddělení build tools od runtime
  • Distroless images — minimal attack surface (žádný shell, package manager)
  • Non-root user — USER nonroot (security best practice)
  • Layer caching — nejdříve kopírovat málo se měnící soubory (package.json → npm ci → code)
  • Small base image — Alpine (5 MB), distroless (minimální), scratch (Go static binary)
  • Healthcheck — HEALTHCHECK instrukce pro orchestrátor
  • Labels — LABEL maintainer, version, git commit
  • .dockerignore — minimalizace build contextu

Artifact management

Docker registries

Registry Public/Private Cena Integrace
Docker Hub Obojí Public free, private $5/měsíc GitHub Actions, GitLab
ECR (AWS) Private $0.10/GB/měsíc + data transfer IAM, ECS, EKS
GHCR (GitHub) Obojí Public free, private 500 MB free GitHub Actions, npm
GCR / Artifact Registry Private $0.10/GB/měsíc GKE, Cloud Build
ACR (Azure) Private $0.11/GB/měsíc AKS, Azure DevOps
Harbor Private (self-hosted) Zdarma (open source) Vlastní, CNCF

Helm charts

  • Repository — index.yaml + chart .tgz na HTTP serveru (S3, GitHub Pages, ChartMuseum)
  • OCI registry — Helm 3.8+ podporuje uložení chartů v OCI registrech (ECR, GHCR, Harbor)
  • Versioning — chart version (balíček) + app version (aplikace)

SBOM (Software Bill of Materials)

  • SPDX / CycloneDX — standardní formáty SBOM
  • Generování: Trivy, Syft, grype
  • Use case: supply chain security, compliance (EO 14028, EU CRA)

Konfigurace a tajemství

Nástroj Popis
Vault (HashiCorp) Dynamic secrets, encryption-as-a-service
AWS Secrets Manager Managed, auto-rotation
Azure Key Vault Managed, HSM podpora
GCP Secret Manager Managed
SOPS Encryption v git repos
Sealed Secrets Encrypted secrets pro Kubernetes

Secret management workflows

Vault agent injector (Kubernetes)

  • Sidecar container (vault-agent) injectuje secrets do podu
  • Secrets mountovány jako tmpfs volume (ne do environment variables)
  • Auto-rotation: vault-agent periodicky refreshuje secrets

External Secrets Operator (Kubernetes)

  • CRD: ExternalSecret → vytváří Secret v K8s
  • Backend: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault
  • Push-based refresh: změna v externím store → propagate do K8s

Sealed Secrets

  • kubeseal zašifruje Secret na clusteru (controller má privátní klíč)
  • Zašifrovaný manifest (SealedSecret) může být bezpečně v gitu
  • Controller decryptuje při deployi

GitOps

  • Princip: Git je jediný zdroj pravdy (single source of truth)
  • Nástroje: ArgoCD, Flux, Rancher Fleet
  • Pull-based deploy — agent v clusteru sleduje repo a aplikuje změny
  • Auto-sync + drift detection

Environment promotion (dev → staging → prod)

Code → Dev (auto-deploy) → Staging (auto + smoke tests) → Prod (manual approval + gating)

Quality gates:

  1. Unit tests — pass rate 100 %, code coverage ≥ 80 %
  2. Integration tests — all critical paths pass
  3. SAST scan — no critical/high vulnerabilities
  4. SCA scan — no known critical CVEs
  5. Container scan — all fixable vulns addressed
  6. Smoke tests — po deployi na staging (health endpoint, basic flow)
  7. Manual approval — pro produkci (volitelné při CD)

Deployment strategie

Strategie Popis Riziko
Rolling update Postupná výměna instancí Nízké
Blue/Green Dvě identická prostředí, přepojení trafficu Střední
Canary % trafficu na novou verzi, postupné zvyšování Nízké
Feature flag Zapnutí/vypnutí funkce bez deploye Velmi nízké
A/B testing Různé verze pro různé uživatele Nízké

Git branching strategies

Strategie Popis Vhodné pro
Trunk-based Jeden hlavní branch (main), krátké feature branche (< 1 den) CD, microservices, mature teams
GitHub Flow Main + feature branche, PRs, jednoduchý Startupy, web apps
GitLab Flow Main + environment branche (staging, prod) + feature branche Enterprise, regulated
GitFlow Develop + main + feature/release/hotfix branche Release-based, enterprise legacy
One Flow Zjednodušený GitFlow (bez develop branche) Střední týmy

Rollback strategies

Strategie Popis Rychlost Riziko
Forward fix Nový deploy s hotfixem Pomalá (build + deploy) Nízké
Rollback (revert commit) Revert gitu, nový deploy Střední Nízké
Blue/Green switchback Přepojení zpět na starou verzi Okamžitá DB inkompatibilita
Database rollback Reverze DB migrace (migrate down) Pomalá Data loss risk

Database rollback challenges

  • Breaking changes — odstranění sloupce/tabulky znamená rollback problém (data ztracena)
  • Best practice: Expand → Migrate → Contract (nikdy neodstraňovat v jednom deployi)
  • Tooling: Flyway undo (limited), Liquibase rollback, pgroll (Postgres)
  • Feature flagy jako prevence — nový kód je za flagem, rollback = vypnutí flagu

CI/CD Design Patterns

Moderní CI/CD pipeline řeší opakující se problémy pomocí návrhových vzorů:

Vzor Popis
Pipeline as Code Pipeline definovaná v YAML/Kotlin DSL (.gitlab-ci.yml, .github/workflows/)
Immutable Pipeline Každý build je artifact, nikdy se nemění
Quality Gate Branch protection, required checks, code coverage threshold
Deployment Strategy Blue/Green, Canary, Rolling (viz tabulka níže)
GitOps Pull-based deploy s auto-sync a drift detection
Shift-Left Security SAST/DAST/SCA součást pipeline
Dependency Caching Cache layer mezi běhy pipeline

Shift left security

SCA (Software Composition Analysis)

Nástroj Typ Integrace
Dependabot GitHub native GitHub, auto-PR na fix
Renovate Multi-platform GitHub, GitLab, Bitbucket
Snyk SaaS + CLI Všechny platformy, Docker, IaC
Trivy CLI, OSS CI/CD pipeline (GitHub Actions, GitLab)

SAST (Static Application Security Testing)

Nástroj Jazyky Charakteristika
Semgrep 30+ (Python, Java, Go, JS/TS) Rychlý, custom rules, CI-native
SonarQube 30+ Komplexní, quality gates, tech debt
CodeQL 12 (C++, C#, Go, Java, JS/TS, Python) GitHub native, query-based
Checkmarx 30+ Enterprise, CxSAST, CxFlow
Fortify 30+ Enterprise, SAST + DAST

Container scanning

Nástroj Popis
Trivy OSS, skenuje OS packages + language-specific + IaC
Grype OSS, od Anchore, rychlý, Syft pro SBOM
Clair Red Hat, OSS, OCI-compatible
Docker Scout Docker Desktop / CLI, integrace s Docker Hub

AI-Native Software Delivery (2025–2026)

AI transformuje DevOps 2.0:

  • AI-assisted CI/CD — automatické diagnózy selhání pipeline, optimalizace resource alokace
  • Agent Control Protocol (ACP) / Model Context Protocol (MCP) — standardy pro interakci AI agentů s toolingem
  • AI-driven cost management — FinOps optimalizace cloudu
  • Intelligent test selection — ML určuje, které testy spustit podle změn v kódu
  • Self-healing pipelines — AI auto-detekuje a opravuje běžné problémy

Nové nástroje: Harness (AI-native CD), GitLab 19.0 (agentic MR workflows, secrets manager), Octopus Deploy.

Nástroje pro pipeline

  • GitHub Actions — integrovaný s GitHubem, velký marketplace
  • GitLab CI — nativní v GitLabu, auto DevOps
  • Jenkins — nejstarší, extensible, self-hosted
  • CircleCI — SaaS, rychlý
  • Argo Workflows — Kubernetes nativní
  • Buildkite — hybrid (vlastní agenti, SaaS orchestrator)

Best practices

  • Idempotentní pipeline — opakované spuštění dává stejný výsledek
  • Immutable infrastructure — nikdy neupravovat running server, vždy znovu nasadit
  • Shift left — testy a security co nejdříve v pipeline
  • Artifact management — všechny buildy verzované v registru (Docker Hub, ECR, GHCR)
  • Dependency caching — urychlení pipeline (npm ci, pip cache, Docker layer caching)
  • Fail fast — pipeline selže co nejdříve při chybě

Zdroje

Odkazy, knihy a standardy: sources/cicd/sources.md

Doporučená literatura

Kniha Autoři ISBN Klíčový přínos
The DevOps Handbook Kim, Humble, Debois, Willis 978-1942788003 Principy CALMS (Culture, Automation, Lean, Measurement, Sharing), flow mapa, deployment pipeline
Continuous Delivery Humble, Farley 978-0321601912 Deployment pipeline, commit stage, acceptance tests, capacity testing, zero-downtime release
CI/CD Design Patterns Bajpai, Schildmeijer, Piwosz, Mishra 978-1-83588-965-7 30+ návrhových vzorů pro CI/CD — pipeline patterns, GitOps, security, testing, deployment strategie
DevOps Frameworks, Techniques, and Tools Vijayakumaran, Kofler, Öggl, Springer 978-1-4932-2670-2 Rámec pro adopci DevOps, srovnání nástrojů (Jenkins vs GitLab vs GitHub Actions), techniky pro monitoring a observabilitu
  • Quality gates — automated checks před každým povýšením do dalšího prostředí
  • Pipeline visibility — dashboard s aktuálním stavem všech pipeline (GitHub, GitLab, ArgoCD)

Poslední revize: 2026-06-03

Reference in New Issue View Git Blame Copy Permalink