Anularea (Rollback) în dezvoltare: ce este, metode și cum funcționează

Ce este anularea și rollback în dezvoltare

Anularea (rollback) — operațiunea de revenire a sistemului la starea stabilă anterioară. în contextul dezvoltării, aceasta poate însemna anularea unui commit în Git, revenirea unei tranzacții în baza de date sau restaurarea versiunii anterioare a aplicației pe server. Termenul provine din englezescul „rollback” și s-a întipărit ferm în vocabularul dezvoltatorilor de pe toate platformele.

Necesitatea anulării apare atunci când o modificare nouă strică funcționalitatea, provoacă erori sau nu trece de controlul de calitate. într-un proces de dezvoltare bine organizat, anularea nu este un semn de eșec, ci o procedură standard încorporată în fluxul de lucru. Cu cât echipa poate anula mai repede o modificare problematică, cu atât impactul bugului asupra utilizatorilor este mai mic.

Diferite instrumente oferă mecanisme diferite de anulare: Git oferă alegerea între revert sigur și reset distructiv, bazele de date acceptă rollback tranzacțional, iar sistemele CI/CD pot comuta traficul între versiuni. Alegerea abordării depinde de context și de cerințele privind păstrarea istoricului modificărilor.

Git revert vs git reset: care este diferența

Git revert — o metodă sigură de anulare care creează un nou commit ce anulează modificările anterioare. Istoricul rămâne liniar, toate commiturile vechi sunt păstrate. Aceasta este singura alegere corectă pentru anularea într-o ramură comună pe care lucrează mai mulți dezvoltatori. Comanda git revert nu șterge istoricul — adaugă faptul anulării ca o modificare nouă.

Git reset mută indicatorul ramurii curente la un commit specificat, renunțând la toate modificările ulterioare. în funcție de flag — soft, mixed sau hard — reset gestionează diferit directorul de lucru și indexul. Modul hard șterge complet modificările din istoric, ceea ce îi face periculos pentru ramurile comune și potrivit doar pentru munca locală.

Când să folosiți revert

Revert se aplică în ramurile partajate: main, develop, release. Păstrează istoricul și permite altor dezvoltatori să înțeleagă că o modificare a fost anulată. După revert se poate face git pull în siguranță — sistemul nu va genera conflicte legate de istoricul rescris. în munca de echipă, revert este standardul implicit.

# Anulează ultimul commit prin crearea unui nou commit
git revert HEAD

# Anulează un anumit commit după hash
git revert a1b2c3d

Când să folosiți reset

Reset este potrivit într-o ramură locală unde încă nu ați publicat modificările. Dacă ați experimentat și doriți să curățați complet istoricul — reset hard va face aceasta. în ramura locală puteți folosi reset mixed pentru a anula commiturile, dar a păstra modificările în directorul de lucru pentru un nou commit.

# Anulează ultimul commit, păstrează modificările în directorul de lucru
git reset HEAD~1

# Anulare completă — modificările sunt șterse definitiv
git reset --hard HEAD~2

Rollback în bazele de date: tranzacții și ACID

Rollback-ul tranzacției — operațiunea care anulează toate modificările efectuate în cadrul tranzacției curente și readuce baza de date la starea de la momentul începerii acesteia. Aceasta garantează atomicitatea — unul dintre cele patru principii ACID (Atomicity, Consistency, Isolation, Durability). Dacă la orice etapă a tranzacției apare o eroare, se execută rollback și datele revin la poziția inițială.

Mecanismul rollback este implementat prin jurnalul de scriere în avans (Write-Ahead Log, WAL). înainte de a modifica o pagină de date, SGBD-ul înregistrează valoarea veche și cea nouă în jurnal. La rollback, sistemul citește jurnalul și restaurează valorile originale pentru toate paginile modificate. Aceasta garantează că, chiar în cazul unei căderi de curent, tranzacția poate fi anulată corect.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: anulare parțială

în tranzacțiile lungi, este convenabil să folosiți savepoint — puncte intermediare de salvare la care puteți reveni fără a încheia întreaga tranzacție. Acest lucru permite gestionarea erorilor în cadrul unei operațiuni complexe fără a pierde progresul în alte părți ale acesteia. Savepoint este acceptat de majoritatea SGBD-urilor relaționale: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Anularea la implementare: strategii și instrumente

Anularea implementării — revenirea aplicației în funcțiune la versiunea anterioară după o implementare nereușită. Aceasta este o capacitate critică pentru mediul de producție: timpul de recuperare (MTTR) influențează direct SLA-ul și experiența utilizatorului. Platformele moderne oferă mai multe strategii de anulare în funcție de arhitectură și cerințele de disponibilitate.

Blue-green deployment

Blue-green — strategia în care două medii identice funcționează simultan: blue (versiunea curentă) și green (versiunea nouă). Traficul este comutat pe green după o implementare reușită. Dacă versiunea nouă funcționează incorect, comutatorul de trafic revine la blue. Anularea se efectuează instantanee, fără a reimplementa — este suficient să schimbați rutarea.

Canary release cu anulare automată

Canary deployment direcționează o mică parte din trafic către versiunea nouă și monitorizează metricile: numărul de erori, timpul de răspuns, procentul de cereri reușite. Dacă metricile se înrăutățesc, sistemul anulează automat canary-ul și direcționează tot traficul către versiunea stabilă. Kubernetes și service mesh-urile (Istio, Linkerd) acceptă această strategie din oficiu.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Exemple practice de anulare în dezvoltare

Să examinăm trei scenarii tipice în care dezvoltatorul trebuie să anuleze modificări. Fiecare scenariu necesită propria abordare — de la o simplă comandă în terminal până la o procedură în mai mulți pași cu participarea CI/CD.

Scenariul 1: commit accidental în main

Ați trimis accidental un commit cu bug în main. Sarcina dumneavoastră este să anulați modificările fără a pierde istoricul pentru echipă. Folosiți git revert pentru a crea un commit de anulare și apoi git push. Toți membrii echipei vor vedea faptul anulării și vor putea continua lucrul fără conflicte. Aceasta este cea mai sigură și mai transparentă metodă.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Scenariul 2: migrare nereușită a bazei de date

Migrarea bazei de date s-a încheiat cu eroare, iar o parte din date a fost deteriorată. Folosiți rollback tranzacțional în scriptul de migrare și restaurarea din backup pentru modificările deja aplicate. într-un sistem bine proiectat, fiecare migrare este înfășurată într-o tranzacție — la eroare, SGBD-ul execută automat rollback.

Scenariul 3: implementare cu bug critic

După implementarea noii versiuni, ați descoperit că autentificarea nu funcționează. Dacă folosiți blue-green, anularea înseamnă comutarea routerului înapoi. Dacă rolling update — comanda kubectl rollout undo va readuce versiunea anterioară. în mod ideal, procesul de anulare ar trebui să fie automatizat și să nu dureze mai mult de un minut.