# 🔄 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

```yaml
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

```yaml
# .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

```yaml
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

```hcl
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

```hcl
# 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

```rego
# 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

```dockerfile
# 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](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)

## OpenStack CI/CD

OpenStack ekosystém používá vlastní CI/CD nástroje:

### Zuul

- CI/CD systém vyvinutý OpenStack komunitou (nyní samostatný, používaný i mimo OpenStack)
- **Gating** — změny se testují před merge (ne po merge) — zabraňuje rozbití main branche
- **Ansible-based** — jobs jsou Ansible playbooky
- **Nodepool** — dynamická alokace testovacích VM v cloudu (OpenStack, AWS)
- **Pipeline** — check, gate, post, periodic, tag, release

### OpenStack Infra (OpenDev)

- Veřejná CI infrastruktura pro OpenStack projekty
- Nástroje: Gerrit (code review), Zuul (CI), Nodepool (test nodes), Storyboard (issue tracking)
- Base jobs: tempest (integration tests), grenade (upgrade tests), devstack-gate (gate tests)

### Integrace s externími nástroji

- **Terraform** — OpenStack provider pro provisioning (terraform-provider-openstack)
- **Ansible** — openstack.cloud collection pro správu OpenStack zdrojů
- **Packer** — build OpenStack images (openstack builder)
- **Jenkins** — starší CI, stále používaný v některých distribucích

*Poslední revize: 2026-06-03*