Kako upravljaš rolls back-e, ko deployment ne uspe?

Question

Accepted Answer

Kadar deployment povzroči težave, moraš **roll back** hitro v delujočo stanje, da čim bolj ominimaš vpliv na uporabnike. Učinkovite strategije za rollback — in povezane prakse spremljanja, avtomatiziranega rollbacka in popravka naprej — so bistvene za zanesljive deploymente.

## Zakaj je sposobnost rollbacka pomembna

```text
Deployments sometimes introduce problems (bugs, errors, performance issues) that get
through testing. When that happens in production:
  → you need to restore a WORKING state QUICKLY (minimize user impact/downtime)
  → a fast, reliable rollback is essential — being able to undo a bad deploy fast
→ "How do we roll back?" must be answered BEFORE you need it.
```

## Pristopi k rollbacku

```text
✓ REDEPLOY the previous version — deploy the last known-good artifact/version
  (versioned artifacts make this easy: deploy v1.2.2 to undo v1.2.3)
✓ BLUE-GREEN → instant rollback by switching traffic back to the old environment
✓ CANARY → if the canary shows problems, stop the rollout (only a few users affected)
✓ Database changes → trickier (need backward-compatible migrations; see below)
✓ Feature FLAGS → disable a problematic feature without redeploying (instant "rollback"
  of behavior)
```

## Pomembna razmišljanja

```text
⚠️ DATABASE migrations → rollbacks are hard if a migration is destructive/incompatible:
  → use BACKWARD-COMPATIBLE migrations (so the old code works with the new schema)
  → decouple schema changes from code; expand-then-contract patterns
✓ MONITORING → detect problems FAST (so you know to roll back) — alerts on errors/metrics
✓ AUTOMATED rollback → some pipelines auto-rollback on failed health checks
✓ FORWARD FIX → sometimes fixing forward (a quick patch) is better than rolling back
✓ Practice/test rollbacks → ensure they actually work when needed
```

## Zakaj je to pomembno

Razumevanje strategij za rollback je pomembno, ker **se deployamenti včasih ne uspejo, in zmožnost hitrega okrevanja je bistvena za zanesljivost**, zato je dragoceno praktično znanje za production deploymente.

Čeprav je testiranje dobro, se deployamenti občasno v produkciji srečajo s težavami, in kadar se to zgodi, je **hitro povrniti delujoče stanje** (da se čim bolj zmanjša vpliv na uporabnike in downtime) kritično — kar naredi rollback sposobnost ključnim delom zanesljivega deployementa, in tisto, ki bi jo bilo treba načrtovati **preden** jo potrebuješ.

Razumevanje **pristopov k rollbacku** — ponovno uvajanje prejšnje različice (omogočeno z verzioniranimi artefakti), trenutnega rollbacka **blue-green** (preusmerjanje prometa nazaj), zaustavitve **canary** rollout-a (omejitev vpliva), in uporabe **feature flags** za onemogočenje problematičnih funkcionalnosti brez ponovnega uvajanja — zagotavlja možnosti, prilagojene različnim strategijam deployementa.

Razumevanje **pomembnih razmišljanj** odraža zrelno prakso deployementa: **migracije baz podatkov otežijo rollbacke** (ker se nereverzibilne ali nezdružljive spremembe sheme ne morejo preprosto razveljaviti), zato je uporaba **nazaj kompatibilnih migracij** (tako da stara koda deluje z novo shemo) in vzorci, kot je expand-then-contract, bistvena — resnično težavna, pomembna praksa iz realnega sveta.

Razumevanje vloge **spremljanja** (hitro odkrivanje težav, da veš, kdaj rollback), **avtomatiziranega rollbacka** (ob neuspelih health check-ih), možnosti **popravka naprej** (včasih je hitri patch boljši od rollbacka), in pomena **testiranja rollbackov** (zagotavljanje, da delujejo, ko so potrebni) odraža celovito razmišljanje o okrevanju deployementa.

Ker se deployamenti lahko ne uspejo in je hitra okrevanje bistvena za zanesljivost (zmanjšanje vpliva na uporabnike), in ker razumevanje pristopov k rollbacku, izziva s selitvijo baz podatkov, in podpornih praks (spremljanje, avtomatizacija, popravek naprej) omogoča učinkovito okrevanje od slabih deployementov, je razumevanje strategij za rollback dragoceno, praktično-pomembno znanje za zanesljive production deploymente — kritični vidik varnosti deployementa, ki odraža operacijsko zrelost, da se spopadeš z neizogibnimi napakami, do katerih pride tudi z dobrim CI/CD.