GitOps a progressive delivery — bezpečný deployment v roce 2026

Kubectl apply v produkci? To snad ne. V roce 2026 je GitOps de facto standard pro deployment do Kubernetes. A progressive delivery strategie zajišťují, že i chybný release nezabije produkci. Jak to celé funguje v praxi?

Co je GitOps a proč vyhrál¶

GitOps je operační model, kde Git je single source of truth pro infrastrukturu i aplikační konfiguraci. Deklarativní stav v Gitu je automaticky synchronizován s cílovým prostředím. Žádné imperative příkazy, žádné ruční zásahy.

Principy GitOps jsou jednoduché: deklarativní popis celého systému, verzovaný a immutable stav v Gitu, automatická aplikace schváleného stavu, a software agenti zajišťující konvergenci a alerting při driftu.

V roce 2026 GitOps adoptovalo přes 70 % organizací provozujících Kubernetes. Důvod je jasný — audit trail, rollback jedním git revert, a eliminace „kdo co kde změnil”.

Argo CD vs Flux — volba nástroje¶

Dva dominantní GitOps kontroléry pro Kubernetes:

• Argo CD: Bohaté UI, application-centric model, silná vizualizace dependency grafu. Lepší pro týmy, které potřebují přehled a self-service portál. CNCF graduated projekt.
• Flux v2: Controller-based architektura, modulární (source, kustomize, helm, notification controllers). Lepší pro platformní týmy budující interní developer platformu. Nativní podpora OCI artefaktů.

V praxi: Argo CD pro application teams (vizuální přehled, sync status, rollback v UI), Flux pro platform teams (composable, API-first, integrace s Terraform). Oboje funguje skvěle.

Repository strategie¶

Jak organizovat Git repozitáře pro GitOps? Tři osvědčené patterny:

• Monorepo: Vše v jednom repozitáři — app code + manifesty. Jednodušší pro malé týmy. Ale: CI/CD pipeline se komplikuje s růstem.
• Separate config repo: Aplikační kód v jednom repo, Kubernetes manifesty v druhém. CI pipeline buildí image → aktualizuje config repo → GitOps agent synchronizuje. Nejčastější pattern v enterprise.
• Repo per environment: Separátní repozitáře pro dev, staging, production. Maximální izolace, ale vyšší správní overhead. Vhodné pro regulované prostředí.

Naše doporučení: separate config repo s branch-per-environment nebo directory-per-environment strukturou. Kustomize overlays pro environment-specifické konfigurace.

Progressive delivery — beyond blue-green¶

GitOps zajistí, že deployment je reprodukovatelný a auditovatelný. Progressive delivery zajistí, že je bezpečný. Strategie od nejjednodušší po nejsofistikovanější:

• Blue-green deployment: Dvě identické prostředí. Traffic se přepne najednou. Rychlý rollback, ale vyžaduje dvojnásobek resources.
• Canary deployment: Nová verze dostává postupně rostoucí procento traffic (1% → 5% → 25% → 100%). Metriky rozhodují o pokračování nebo rollbacku.
• A/B testing: Různé verze pro různé segmenty uživatelů. Vyžaduje traffic splitting na úrovni service mesh.
• Feature flags: Kód je nasazen, ale funkce je skrytá za flag. Gradual rollout bez nového deploymentu. Nejflexibilnější, ale vyžaduje disciplínu ve správě flags.

Canary v praxi s Argo Rollouts¶

Argo Rollouts je Kubernetes controller, který nahrazuje standardní Deployment resource a přidává progressive delivery strategie. Typický canary flow:

• Krok 1: Nová verze se nasadí s 5 % traffic. Automatická analýza metrik (success rate, latence, error rate) po dobu 5 minut.
• Krok 2: Pokud metriky vyhovují, traffic se zvýší na 25 %. Další analýza.
• Krok 3: 50 % traffic. V tomto bodě je vhodný human approval gate pro kritické služby.
• Krok 4: 100 % traffic. Canary se stává novou stable verzí.

Klíčové: automatická analýza metrik rozhoduje o promotion nebo rollbacku. Argo Rollouts se integruje s Prometheus, Datadog, New Relic a dalšími. Pokud error rate překročí threshold, rollback proběhne automaticky — bez zásahu člověka.

Service mesh a traffic management¶

Pro sofistikovaný traffic splitting potřebujete service mesh nebo ingress controller s odpovídajícími schopnostmi:

• Istio: Nejkompletnější řešení. VirtualService pro traffic splitting, DestinationRule pro load balancing. Ale: vysoká komplexita a resource overhead.
• Linkerd: Lightweight alternativa. Rust-based proxy, nízká latence. Traffic splitting přes SMI (Service Mesh Interface) nebo HTTPRoute.
• Gateway API + NGINX/Envoy: Bez full service mesh. Kubernetes Gateway API standard s traffic splitting podporou. Nejjednodušší cesta pro canary.

Feature flags — deployment ≠ release¶

Oddělení deploymentu od releasu je game changer. S feature flags můžete:

• Trunk-based development: Vše jde do main, nehotové features jsou za flagem. Žádné dlouhé feature branches.
• Gradual rollout: Feature zapnete pro 1 % uživatelů, měříte dopad, postupně rozšiřujete.
• Kill switch: Problémová feature se vypne okamžitě, bez nového deploymentu.
• Targeting: Feature pro konkrétní zákaznický segment, region nebo environment.

Nástroje: LaunchDarkly (enterprise), Unleash (open-source, self-hosted), OpenFeature (vendor-neutral SDK standard). Pro české firmy často doporučujeme Unleash — self-hosted, GDPR friendly, dostatečně robustní.

Observability-driven deployment¶

Progressive delivery bez observability je jako řídit auto se zavřenýma očima. Minimální setup:

• Zlaté signály: Latence, traffic, error rate, saturace — pro každou službu.
• SLO-based promotion: Canary pokračuje, pouze pokud SLO drží. Burn rate alerting odhalí degradaci dříve než threshold-based alerty.
• Deployment markers: Anotace v Grafana/Datadog ukazují, kdy proběhl deployment. Korelace s metrikami je okamžitě viditelná.
• Automated rollback: Pokud SLO burn rate překročí limit, Argo Rollouts automaticky vrátí na předchozí verzi.

Deploy often, deploy safely¶

GitOps + progressive delivery = nasazujte častěji s nižším rizikem. Automatická synchronizace z Gitu eliminuje konfigurační drift. Canary a feature flags zajistí, že chybný release zasáhne minimum uživatelů.

Náš tip: Začněte GitOps pro non-production prostředí. Když si tým zvykne na workflow, rozšiřte na production s canary deploymentem. Feature flags přidejte tam, kde potřebujete oddělení release od deploy cyklu.