Kako rukuješ vraćanjem na prethodnu verziju kada se implementacija ne uspije?

Question

Accepted Answer

Kada implementacija uvede probleme, trebate se **brzo vratiti** na radeće stanje kako biste minimizirali utjecaj na korisnike. Učinkovite strategije vraćanja — i povezane prakse nadzora, automatskog vraćanja i rješavanja problema naprijed — bitne su za pouzdane implementacije.

## Zašto je mogućnost vraćanja važna

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

## Pristupi vraćanju

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

## Važna razmatranja

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

## Zašto je važno

Razumijevanje strategija vraćanja je važno jer **implementacije ponekad neuspiju, a mogućnost brzog oporavka je bitna za pouzdanost**, pa je to dragocjena praktična znanja za produkcijske implementacije.

Čak i uz dobro testiranje, implementacije ponekad uvode probleme u produkciji, a kada se to dogodi, **brzo vraćanje u radeće stanje** (kako bi se minimizirao utjecaj na korisnike i vrijeme neaktivnosti) je kritično — čineći mogućnost vraćanja ključnim dijelom pouzdane implementacije, i onim što bi trebalo biti planirano **prije** nego što bude potrebno.

Razumijevanje **pristupa vraćanju** — ponovno postavljanje prethodne verzije (olakšane verzioniranim artefaktima), trenutnog vraćanja **modre-zelene** (prebacivanje prometa), zaustavljanja **kanarske** imple mentacije (ograničavanje utjecaja) i korištenja **feature flagova** za onemogućavanje problematičnih značajki bez ponovne implementacije — pruža opcije prilagođene različitim strategijama implementacije.

Razumijevanje **važnih razmatranja** odražava zrelu praksu implementacije: **migracije baze podataka otežavaju vraćanje** (jer se destruktivne ili nekompatibilne promjene sheme ne mogu jednostavno opozvati), pa korištenje **kompatibilnih migracija** (tako da stari kod radi s novom shemom) i načini kao expand-then-contract su bitni — doista teško, važno praktično pitanje.

Razumijevanje uloge **nadzora** (brzo otkrivanje problema kako biste znali da trebate vratiti), **automatskog vraćanja** (na neuspješne provjere zdravlja), mogućnosti **rješavanja problema naprijed** (ponekad je brza ispravka bolja od vraćanja) i važnosti **testiranja vraćanja** (osiguravanja da rade kada su potrebni) odražava sveobuhvatno razmišljanje o oporavku od implementacije.

Budući da se implementacije mogu neuspješiti i brz oporavak je bitan za pouzdanost (minimiziranje utjecaja na korisnike), a budući da razumijevanje pristupa vraćanju, izazova migracije baze podataka i prateće prakse (nadzor, automatizacija, rješavanje naprijed) omogućava učinkovito oporavak od loših implementacija, razumijevanje strategija vraćanja je dragocjena, praktično važna znanja za pouzdane produkcijske implementacije — kritični aspekt sigurnosti implementacije, odražavajući operativnu zrelost za rukovanje neizbježnim greškama koje se pojavljuju čak i s dobrim CI/CD.