🟡 Intermediate

Deployment Strategies — Stratégie nasadzovania

Spôsob, akým nasadzuješ novú verziu aplikácie, priamo ovplyvňuje dostupnosť služby, rýchlosť rollbacku a riziko pre používateľov. Výber správnej deployment stratégie je rovnako dôležitý ako samotný kód.

Prečo na deployment stratégii záleží

  • Zero-downtime — používatelia očakávajú nepretržitú dostupnosť
  • Rýchly rollback — ak niečo zlyhá, musíš sa vedieť vrátiť za sekundy
  • Postupné overenie — nová verzia by mala prejsť validáciou skôr, než ju uvidí 100 % traffic-u
  • Bezpečnosť dát — migrácie databázy musia byť kompatibilné s oboma verziami

Recreate (najjednoduchší prístup)

Zastav starú verziu → nasaď novú → spusti.

v1 ████████ STOP
                  v2 ████████ START
     ↑ downtime ↑

Výhody:

  • Najjednoduchšia implementácia
  • Žiadne konflikty medzi verziami
  • Nízke nároky na infraštruktúru

Nevýhody:

  • Downtime — služba je nedostupná počas nasadenia
  • Nevhodné pre produkčné systémy s SLA

Kedy použiť: Dev/staging prostredia, interné nástroje s plánovanou údržbou.

Rolling Update

Postupne nahrádza staré inštancie novými, jednu po druhej.

Pod 1: v1 → v2
Pod 2: v1 ——→ v2
Pod 3: v1 ————→ v2
Pod 4: v1 ——————→ v2

Ako funguje:

  1. Spustí sa nová inštancia (v2)
  2. Health check potvrdí, že je ready
  3. Stará inštancia (v1) sa odstráni
  4. Opakuj pre ďalšie inštancie

Výhody:

  • Zero-downtime
  • Postupné nasadenie znižuje riziko
  • Natívna podpora v Kubernetes (strategy: RollingUpdate)

Nevýhody:

  • Počas rollout-u bežia obe verzie súčasne — API musí byť backward-compatible
  • Pomalší rollback (musíš rolling update späť)
  • Ťažšie testovanie s dvoma verziami naraz
# Kubernetes rolling update
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Blue/Green Deployment

Dva identické prostredia — Blue (aktuálna verzia) a Green (nová verzia). Traffic sa prepne naraz.

                    Load Balancer
                    /          \
  Blue (v1) ← traffic    Green (v2) ← idle
                    
  Po overení:
  Blue (v1) ← idle       Green (v2) ← traffic

Ako funguje:

  1. Green prostredie sa nasadí s novou verziou
  2. Testy bežia proti Green
  3. Load balancer prepne traffic z Blue na Green
  4. Blue zostáva ako okamžitý rollback

Výhody:

  • Okamžitý rollback — stačí prepnúť traffic späť
  • Nová verzia je plne otestovaná pred prepnutím
  • Zero-downtime

Nevýhody:

  • Dvojnásobné náklady na infraštruktúru
  • Databázové migrácie musia byť kompatibilné s oboma verziami
  • Komplexnejšia správa prostredí

Rollback: Prepni load balancer späť na Blue — hotovo za sekundy.

Canary Deployment

Nová verzia sa najprv nasadí pre malé percento používateľov. Ak metriky vyzerajú dobre, traffic sa postupne zvyšuje.

Fáza 1:  v1 ████████████████████  95%
          v2 █                      5%

Fáza 2:  v1 ████████████████      80%
          v2 ████                  20%

Fáza 3:  v1 ██████████            50%
          v2 ██████████            50%

Fáza 4:  v2 ████████████████████ 100%

Kľúčové metriky na sledovanie:

  • Error rate (4xx, 5xx)
  • Latencia (p50, p95, p99)
  • CPU/memory využitie
  • Business metriky (konverzie, bounce rate)

Výhody:

  • Minimálny dopad pri chybe — ovplyvnený len malý % používateľov
  • Reálne produkčné testovanie
  • Dáta-driven rozhodovanie o rollout-e

Nevýhody:

  • Komplexný setup (traffic splitting, monitoring)
  • Pomalší rollout
  • Vyžaduje dobrý observability stack

A/B Testing vs Canary

Canary A/B Testing
Cieľ Technická stabilita Biznis metriky (UX, konverzie)
Routing Náhodný % traffic-u Podľa segmentov (geo, user group)
Metriky Error rate, latencia CTR, konverzia, engagement
Trvanie Hodiny Dni až týždne
Rollback trigger Technické chyby Štatistická signifikancia

Canary overuje či to funguje. A/B testing overuje či to funguje lepšie.

Feature Flags ako alternatíva

Namiesto deployment stratégie môžeš nový kód nasadiť vypnutý a zapínať ho postupne cez feature flags.

if (featureFlags.isEnabled('new-checkout', { userId })) {
  return newCheckoutFlow();
} else {
  return oldCheckoutFlow();
}

Výhody:

  • Decouple deployment od release-u
  • Okamžitý rollback — vypni flag
  • Granulárna kontrola (per user, per region)
  • Možnosť A/B testovania bez infra zmien

Nevýhody:

  • Technický dlh — staré flagy treba čistiť
  • Komplexita kódu (vetvenie logiky)
  • Vyžaduje feature flag systém (LaunchDarkly, Unleash, Flagsmith)

Shadow / Dark Deployment

Produkčný traffic sa duplikuje na novú verziu, ale odpovede sa zahadzujú. Používateľ vidí len odpoveď zo starej verzie.

Request → v1 (produkcia) → Response pre používateľa
       ↘ v2 (shadow)     → Response zahodený (len logging)

Výhody:

  • Nulové riziko pre používateľov
  • Testovanie s reálnym traffic-om
  • Ideálne pre performance testing a ML modely

Nevýhody:

  • Dvojnásobná záťaž na backend
  • Side-effecty (write operácie) sa musia špeciálne riešiť
  • Komplexná implementácia

Porovnávacia tabuľka stratégií

Stratégia Downtime Rollback Reálny traffic test Náklady na infra Komplexita
Recreate ✅ Áno Pomalý ❌ Nízke Nízka
Rolling Update ❌ Nie Pomalý Čiastočný Nízke Stredná
Blue/Green ❌ Nie Okamžitý ❌ Vysoké (2×) Stredná
Canary ❌ Nie Rýchly ✅ Stredné Vysoká
Feature Flags ❌ Nie Okamžitý ✅ Nízke Stredná
Shadow ❌ Nie N/A ✅ Vysoké (2×) Vysoká

Best Practices

Health Checks

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3
  • Liveness — je proces živý? (restart ak nie)
  • Readiness — je pripravený prijímať traffic? (odstráň z LB ak nie)

Rollback plán

  1. Definuj rollback trigger — error rate > 1%, latencia > 500ms
  2. Automatizuj rollback — manuálny rollback o 3:00 ráno nefunguje
  3. Testuj rollback pravidelne — rollback, ktorý si nikdy neskúšal, je len teória
  4. Databázové migrácie — vždy backward-compatible (expand-contract pattern)

Monitoring počas deploymentu

  • Dashboardy — dedikovaný deployment dashboard s kľúčovými metrikami
  • Alerting — automatické alerty pri anomáliách počas rollout-u
  • Porovnanie — metriky v1 vs v2 side-by-side
  • Log aggregácia — centralizované logy pre obe verzie

Ďalšie odporúčania

  • Infraštruktúra ako kód — deployment proces musí byť reprodukovateľný
  • Immutable artifacts — rovnaký Docker image pre všetky prostredia
  • Progressive delivery — kombinuj canary + feature flags + automatizované gates
  • Chaos engineering — testuj, čo sa stane keď deployment zlyhá uprostred

Zhrnutie

Neexistuje jedna „najlepšia" stratégia. Výber závisí od:

  • Tolerancie na downtime — Recreate vs. všetko ostatné
  • Rýchlosti rollbacku — Blue/Green a feature flags vyhrávajú
  • Rozpočtu — Blue/Green a shadow vyžadujú dvojnásobnú infraštruktúru
  • Observability — Canary vyžaduje silný monitoring stack

Pre väčšinu tímov je Rolling Update dobrý štart. Ako rastieš, pridaj Canary a Feature Flags pre kritické služby.