Deployment v éře AI: proč se nasazování stalo úzkým hrdlem

Co se ve skutečnosti změnilo

Do roku 2023 platila jednoduchá rovnice: největší část dodávky software zabíralo psaní kódu. Všechny investice do produktivity - lepší IDE, knihovny, frameworky - mířily sem, protože právě tady se čekalo nejdéle.

AI asistenti tuhle rovnici rozbili. Vývojář dnes vygeneruje CRUD službu, migraci databáze i sadu testů za odpoledne. Jenže psaní kódu byla jen jedna fáze z osmi. Zbytek cesty do produkce - review, testy, příprava prostředí, konfigurace, schválení, nasazení, ověření - zůstal přesně tam, kde byl.

Výsledek zná každý, kdo to zažil: tým "dodává" víc, ale zákazník nic nedostává rychleji. Práce se jen hromadí ve frontě před nasazením. Klasické pravidlo teorie omezení říká, že zrychlení kroku, který není úzkým hrdlem, nezvýší průchodnost systému - jen zvětší zásobu rozpracované práce před skutečným omezením.

Čísla, která to potvrzují

Zpráva DORA 2025 (Google Cloud) uvádí, že AI nástroje používá zhruba 90 % vývojářů a poprvé se adopce AI pozitivně promítá do průtoku dodávky. Stejná zpráva ale současně ukazuje, že adopce AI koreluje s vyšší nestabilitou: více selhaných změn, více přepracování a delší doba na vyřešení problémů.

Telemetrická studie Faros AI napříč více než 10 000 vývojáři a 1 255 týmy dává tomu posunu konkrétní tvar - a je z ní dobře vidět, kam se úzké hrdlo přesunulo:

Jinými slovy: vývojáři produkují dvojnásobek změn, změny jsou 2,5× větší a čekání na review se prodloužilo. To je definice úzkého hrdla. Novější data ze stejného zdroje ukazují, že tlak dál roste - medián času v review se meziročně zvýšil násobně a rostoucí podíl PR se mergne úplně bez review, protože kapacita recenzentů prostě nestačí.

Kde přesně nové úzké hrdlo vzniká

Než začnete cokoli automatizovat, je potřeba vědět, kde se práce zdržuje. V praxi to bývá těchto pět míst:

1. Verifikace místo psaní

AI přesunula námahu z tvorby na ověřování. Recenzent dnes čte kód, který nikdo z týmu nepsal, v objemu, na jaký nebyl proces navržený. Bez automatických testů, statické analýzy a jasných pravidel se review mění na nekonečné čtení.

2. Čekání na prostředí

Pokud má tým tři sdílená testovací prostředí a deset paralelních změn, sedm změn čeká. Sdílené staging prostředí je v éře AI to nejdražší omezení, které si můžete nechat.

3. Setup nového projektu

Nová služba vzniká za den, ale její pipeline, prostředí, DNS, certifikáty, secrets, monitoring a alerty se skládají ručně dva týdny. To je čistá režie, kterou lze téměř úplně odstranit šablonami.

4. Manuální kroky v release procesu

Ruční schvalování, ruční migrace databáze, ruční přepínání trafficu, "ještě to musí potvrdit kolega". Každý manuální krok má fixní cenu v řádu hodin či dnů a s rostoucím počtem změn se násobí.

5. Chybějící bezpečnostní síť

Když se tým bojí nasazovat, nasazuje méně často a ve větších dávkách - což riziko dál zvyšuje. Bez rychlého a automatického rollbacku nelze zvýšit frekvenci nasazení, ať už kód píše kdokoli.

Rychlý test: je vaše nasazování brzda?

Projděte si tento seznam. Každá nezaškrtnutá položka je konkrétní zdržení.

Méně než šest zaškrtnutých položek znamená, že vaše největší investice do rychlosti vývoje momentálně nepatří do dalších AI licencí, ale do deployment pipeline.

Řešení 1: Šablona projektu, ne kopírování

Nejrychlejší návratnost má standardizace startu projektu. Cílem je jeden příkaz, po kterém existuje funkční služba nasazená do dev prostředí - včetně pipeline, health checků, dashboardu a alertů.

Co má šablona obsahovat

service-template/
├── .github/workflows/
│   ├── ci.yaml              # build, testy, SAST, SCA, scan image, SBOM, podpis
│   └── release.yaml         # tag → push do registry → bump verze v GitOps repu
├── deploy/
│   ├── Chart.yaml           # závislost na sdíleném library chartu
│   ├── values.yaml          # jen to, co je pro službu specifické
│   └── overlays/
│       ├── dev/
│       ├── staging/
│       └── prod/
├── docs/
│   ├── README.md            # jak službu spustit lokálně
│   └── runbook.md           # co dělat, když hoří
├── observability/
│   ├── dashboard.json       # Grafana dashboard jako kód
│   └── alerts.yaml          # SLO a alerty jako kód
├── catalog-info.yaml        # registrace do katalogu služeb (Backstage)
├── Dockerfile               # distroless, non-root, multi-stage
└── CODEOWNERS

Struktura šablony služby - vše, co nová služba potřebuje k životu v produkci.

Jak šablonu spouštět

Na malé škále stačí cookiecutter, copier nebo nativní template repository v GitHubu. Od zhruba deseti týmů výš se vyplatí developer portál (Backstage nebo obdoba), kde je založení služby formulář a vývojář nemusí znát vnitřek platformy:

# Backstage Software Template (zkráceno)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service
  title: Node.js služba (produkční standard)
spec:
  parameters:
    - title: Základní údaje
      required: [name, owner, tier]
      properties:
        name:  { type: string, title: Název služby }
        owner: { type: string, title: Vlastnící tým }
        tier:  { type: string, enum: [tier-1, tier-2, tier-3] }
  steps:
    - id: fetch
      action: fetch:template
      input: { url: ./skeleton, values: { name: '${{ parameters.name }}' } }
    - id: publish
      action: publish:github
      input: { repoUrl: 'github.com?repo=${{ parameters.name }}&owner=acme' }
    - id: register-gitops
      action: github:pull-request        # PR do GitOps repozitáře
      input: { repoUrl: 'github.com?repo=platform-gitops&owner=acme' }

Jeden formulář vytvoří repozitář, pipeline i záznam v GitOps repu.

Řešení 2: Kubernetes jako šablona nasazení

Kubernetes je v tomto kontextu především jednotný deklarativní model. Když každá služba popisuje své nasazení stejným jazykem, dá se ta část, která je pro všechny stejná, vytknout do sdílené šablony. Nová služba pak zdarma dědí health checky, limity, autoscaling, síťové politiky i rollback strategii.

Vrstva 1: sdílený Helm library chart

Library chart obsahuje šablony, ale sám se nenasazuje. Je to standard vaší platformy vyjádřený v kódu:

# platform-library/Chart.yaml
apiVersion: v2
name: platform-library
type: library          # klíčové: nenasazuje se, jen poskytuje šablony
version: 2.4.0

# platform-library/templates/_deployment.tpl
{{- define "platform.deployment" -}}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas | default 3 }}
  strategy:
    rollingUpdate: { maxUnavailable: 0, maxSurge: 1 }
  template:
    spec:
      securityContext: { runAsNonRoot: true, seccompProfile: { type: RuntimeDefault } }
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          readinessProbe:
            httpGet: { path: /healthz/ready, port: http }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /healthz/live, port: http }
            periodSeconds: 10
          lifecycle:
            preStop: { exec: { command: ["sleep", "10"] } }   # graceful shutdown
          resources:
            requests: { cpu: {{ .Values.resources.cpu }}, memory: {{ .Values.resources.memory }} }
{{- end -}}

Standard platformy: nikdo už nemusí přemýšlet nad probes, security contextem ani rolling update strategií.

Služba pak potřebuje jen tohle:

# payments-api/deploy/Chart.yaml
dependencies:
  - name: platform-library
    version: "2.4.0"
    repository: "oci://registry.acme.cz/charts"

# payments-api/deploy/values.yaml
name: payments-api
image:
  repository: registry.acme.cz/payments-api
replicas: 4
resources: { cpu: 500m, memory: 512Mi }

Celá konfigurace nasazení nové služby - šest řádků místo šesti set.

Vrstva 2: Kustomize overlays pro prostředí

Rozdíly mezi prostředími nepatří do šablony, ale do overlays. Base je jeden, overlay mění jen to nutné:

# overlays/prod/kustomization.yaml
resources:
  - ../../base
replicas:
  - name: payments-api
    count: 8
patches:
  - target: { kind: Deployment, name: payments-api }
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: 1Gi
configMapGenerator:
  - name: app-config
    envs: [prod.env]

Dev, staging a produkce sdílejí jeden base - konfigurační drift mezi prostředími prakticky zaniká.

Vrstva 3: jedna definice pro všechny služby

Argo CD ApplicationSet vygeneruje nasazení pro každou službu i cluster automaticky. Přidání služby do platformy je pak jeden adresář v GitOps repozitáři:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: services
  namespace: argocd
spec:
  generators:
    - matrix:
        generators:
          - git:                                  # každá služba = adresář v repu
              repoURL: https://github.com/acme/platform-gitops
              revision: HEAD
              directories: [{ path: services/* }]
          - list:                                 # cílová prostředí
              elements:
                - env: staging
                  cluster: https://staging.k8s.acme.cz
                - env: prod
                  cluster: https://prod.k8s.acme.cz
  template:
    metadata:
      name: '{{ path.basename }}-{{ env }}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/platform-gitops
        path: '{{ path }}/overlays/{{ env }}'
      destination:
        server: '{{ cluster }}'
        namespace: '{{ path.basename }}'
      syncPolicy:
        automated: { prune: true, selfHeal: true }
        retry: { limit: 5 }

Nová služba = nový adresář. Nasazení do všech prostředí vznikne samo.

Řešení 3: GitOps místo deployment skriptů

Pokud pipeline nasazuje příkazem kubectl apply z CI runneru, nemáte ověřitelný stav produkce - máte historii běhů. GitOps model tohle obrací: požadovaný stav je v Gitu, kontroler v clusteru se stará o to, aby realita odpovídala.

• Auditovatelnost: každá změna produkce je commit s autorem a review.
• Rollback: git revert místo hledání, co vlastně poslední deploy udělal.
• Odstranění driftu: ruční změna v clusteru se sama vrátí zpět (selfHeal).
• Bezpečnost: CI nepotřebuje přístup do clusteru - stačí právo zapsat do repozitáře.

V éře AI má tenhle model ještě jeden efekt: audit trail nezávisí na tom, kdo (nebo co) kód napsal. Ať změnu vygeneroval člověk, nebo agent, do produkce vede jedna auditovatelná cesta.

Řešení 4: Automatická bezpečnostní síť

Tohle je nejdůležitější změna myšlení. Při objemu změn, který AI generuje, člověk přestává být použitelnou pojistkou. Recenzent nezachytí subtilní chybu ve 400řádkovém PR, který za den dostane pětkrát. Systém ji zachytit může - v produkci, na malém procentu trafficu, a sám změnu vrátit.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payments-api
spec:
  strategy:
    canary:
      analysis:
        templates: [{ templateName: success-rate }]
        startingStep: 1                  # analyzuj od 10 % trafficu
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 1m
      successCondition: result[0] >= 0.99
      failureLimit: 2                    # 2 selhání → automatický rollback
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{service="payments-api",code!~"5.."}[2m]))
            /
            sum(rate(http_requests_total{service="payments-api"}[2m]))

Canary s automatickou analýzou: vadná verze se sama stáhne dřív, než ji zaznamená většina uživatelů.

Řešení 5: Dočasné prostředí pro každý pull request

Sdílený staging je fronta. Když má každý PR vlastní namespace s vlastní instancí aplikace, mizí čekání i vzájemné blokování - a testování se přesouvá před merge, kde je oprava nejlevnější.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: preview-environments
spec:
  generators:
    - pullRequest:
        github: { owner: acme, repo: payments-api }
        requeueAfterSeconds: 60
  template:
    metadata:
      name: 'payments-api-pr-{{ number }}'
    spec:
      source:
        repoURL: https://github.com/acme/payments-api
        targetRevision: '{{ head_sha }}'
        path: deploy
        helm:
          parameters:
            - { name: image.tag, value: '{{ head_sha }}' }
            - { name: ingress.host, value: 'pr-{{ number }}.preview.acme.cz' }
      destination:
        namespace: 'preview-pr-{{ number }}'
      syncPolicy:
        automated: { prune: true }
        syncOptions: [CreateNamespace=true]

Prostředí vznikne s otevřením PR a zanikne s jeho zavřením - včetně úklidu zdrojů.

Dvě praktické poznámky: preview prostředí musí mít tvrdý limit životnosti (jinak vám cloudové náklady utečou) a nesmí sahat na produkční data - použijte seedovaná testovací data nebo anonymizovanou kopii.

Řešení 6: Guardrails jako kód

AI generuje kód rychle, ale bez kontextu vašich provozních a bezpečnostních pravidel. Ta pravidla proto musí být vynucená platformou, ne domluvou. Prakticky to znamená tři vrstvy kontrol:

# Kyverno: do produkce jen podepsané image z vlastního registru
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        any:
          - resources: { kinds: [Pod], namespaces: ["prod-*"] }
      verifyImages:
        - imageReferences: ["registry.acme.cz/*"]
          attestors:
            - entries:
                - keys: { publicKeys: |-
                    -----BEGIN PUBLIC KEY-----
                    ...
                    -----END PUBLIC KEY----- }

Pravidlo, které nelze obejít spěchem ani přehlédnout v review.

Zásadní je, že tyhle kontroly patří do šablony projektu. Pokud si je každý tým musí zapnout sám, polovina to neudělá. Pokud jsou v šabloně, jsou všude od prvního dne - a platform tým je může centrálně aktualizovat.

Řešení 7: Měřte fronty, ne aktivitu

Počet commitů nebo mergnutých PR v éře AI o výkonu nevypovídá skoro nic - to číslo poroste, i když se do produkce nedostane nic navíc. Sledujte čtyři DORA metriky a doplňte je o čekací doby v jednotlivých fázích:

• Frekvence nasazení - kolikrát denně se změna dostane k uživatelům.
• Doba od commitu do produkce - rozdělená na fáze, ne jako jedno číslo.
• Change failure rate - podíl nasazení, která způsobí problém.
• Doba obnovy - jak rychle se vracíte do funkčního stavu.
• Čas do prvního review - první místo, kde se dnes tvoří fronta.
• Čas mezi merge a produkcí - čistá režie vašeho release procesu.
• Podíl PR mergnutých bez review - včasný indikátor přetížení týmu.

Pokud první dvě metriky rostou a zbylé se zhoršují, jedete rychleji do zdi - přesně ten vzorec, který DORA 2025 popisuje jako vyšší průtok při vyšší nestabilitě.

Plán na 90 dní

Není potřeba přestavět platformu naráz. Tohle pořadí dává nejvyšší efekt na vynaloženou práci:

Dny 1-30: změřit a standardizovat jednu cestu

• Změřte skutečné čekací doby ve fázích (commit → review → merge → produkce).
• Vyberte jednu reprezentativní službu a doveďte ji ke GitOps nasazení.
• Popište standard nasazení jako Helm library chart verze 0.1.

Dny 31-60: zašablonovat a odstranit fronty

• Vytvořte šablonu projektu se vším: CI, chart, alerty, runbook, policy.
• Založte z ní minimálně dvě nové služby - šablona bez uživatelů je mrtvá.
• Zapněte preview prostředí pro pull requesty u nejaktivnějšího repozitáře.

Dny 61-90: nahradit lidskou pojistku automatikou

• Zaveďte canary s automatickou analýzou u jedné produkční služby.
• Přidejte admission policy (podepsané image, žádný root, povinné limity).
• Zrušte manuální schvalovací kroky, které nahradila automatická kontrola.
• Zveřejněte metriky týmům - viditelnost je polovina zlepšení.

Pět chyb, které tenhle přechod nejčastěji zabijí

1. Šablona bez vlastníka. Nikdo ji neaktualizuje, za půl roku je zastaralá a týmy se vrátí ke copy-paste.
2. Platforma jako povinnost bez přínosu. Pokud je vlastní řešení pro tým rychlejší než vaše šablona, prohráli jste. Zlatá cesta musí být nejsnazší cesta.
3. Automatizace nad chaosem. Zautomatizovat nekonzistentní ruční proces znamená vyrábět chyby rychleji. Nejdřív standardizace, pak automatizace.
4. Rychlost bez pojistky. Zvýšit frekvenci nasazení bez automatického rollbacku a observability je nejjistější cesta k výpadku.
5. AI mimo pravidla. Pokud AI generovaný kód obchází stejné kontroly jako lidský, dřív nebo později se to projeví v produkci.

Často kladené otázky

Klíčové poznatky

• Úzké hrdlo se přesunulo. Není to psaní kódu, ale cesta od commitu do produkce.
• Rychlejší generování kódu bez rychlejšího nasazování jen zvětšuje frontu - a s ní i riziko.
• Šablony jsou nejrychlejší výhra. Nová služba do 30 minut, se všemi standardy zabudovanými.
• Kubernetes používejte jako sdílenou šablonu - library chart, overlays, ApplicationSet - ne jako cíl sám o sobě.
• Bezpečnostní síť musí být automatická. Canary, analýza metrik, rollback, policy as code.
• Měřte fronty, ne aktivitu. DORA metriky plus čekací doby ve fázích ukážou pravdu.

Související články