Visszavonás (Rollback) a fejlesztésben: mi ez, módszerek és hogyan működik

Mi a visszavonás és rollback a fejlesztésben

Visszavonás (rollback) — a rendszer előző stabil állapotba való visszaállításának művelete. A fejlesztés kontextusában ez jelentheti egy commit visszavonását Git-ben, egy tranzakció visszállítását az adatbázisban vagy az alkalmazás előző verziójának visszaállítását a szerveren. A kifejezés az angol „rollback” szóból származik és szilárdan beépült az összes platform fejlesztőinek szókincsébe.

A visszavonás szükségessége akkor merül fel, amikor egy új változtatás megtöri a funkcionalitást, hibákat okoz vagy nem megy át a minőségellenőrzésen. Egy jól szervezett fejlesztési folyamatban a visszavonás nem a kudarc jele, hanem a munkafolyamatba épített standard eljárás. Minél gyorsabban tudja a csapat visszavonni a problémás változtatást, annál kisebb a hiba hatása a felhasználókra.

Különböző eszközök különböző visszavonási mechanizmusokat kínálnak: Git választást ad a biztonságos revert és a destruktív reset között, az adatbázisok támogatják a tranzakciós rollbacket, a CI/CD rendszerek pedig képesek váltani a forgalmat a verziók között. A megközelítés választása a kontextustól és a változtatások történetének megőrzésére vonatkozó követelményektől függ.

Git revert vs git reset: mi a különbség

Git revert — biztonságos visszavonási mód, amely új commitot hoz létre, visszavonva az előző változtatásait. A történet lineáris marad, az összes régi commit megmarad. Ez az egyetlen helyes választás a közös ágban történő visszavonáshoz, ahol több fejlesztő dolgozik. A git revert parancs nem törli a történetet — hozzáadja a visszavonás tényét új változtatásként.

Git reset az aktuális ág mutatóját a megadott commitra mozgatja, eldobva az összes későbbi változtatást. A zászlótól függően — soft, mixed vagy hard — a reset különbözően kezeli a munkakönyvtárat és az indexet. A hard mód teljesen eltávolítja a változtatásokat a történetből, ami veszélyessé teszi a közös ágak számára és csak helyi munkára alkalmas.

Mikor használjuk a revertet

Revert megosztott ágakban alkalmazzuk: main, develop, release. Megőrzi a történetet és lehetővé teszi más fejlesztők számára, hogy megértsék, egy változtatás vissza lett vonva. Revert után biztonságosan végrehajtható a git pull — a rendszer nem generál az átírt történettel kapcsolatos konfliktusokat. Csapatmunkában a revert az alapértelmezett standard.

# Az utolsó commit visszavonása új commit létrehozásával
git revert HEAD

# Egy adott commit visszavonása hash alapján
git revert a1b2c3d

Mikor használjuk a resetet

Reset helyi ágban alkalmas, ahol még nem publikálta a változtatásokat. Ha kísérletezett és teljesen ki szeretné tisztítani a történetet — a reset hard megteszi. Helyi ágban használhatja a reset mixedet a commitok visszavonására, de a változtatások megtartására a munkakönyvtárban az újracommitoláshoz.

# Az utolsó commit visszavonása, változtatások megtartása a munkakönyvtárban
git reset HEAD~1

# Teljes visszavonás — a változtatások végleg eltávolítva
git reset --hard HEAD~2

Rollback az adatbázisokban: tranzakciók és ACID

Tranzakció rollback — művelet, amely visszavonja az aktuális tranzakció keretében végzett összes változtatást és visszaállítja az adatbázist a kezdeti állapotába. Ez garantálja az atomosságot — az ACID (Atomicity, Consistency, Isolation, Durability) négy alapelvének egyikét. Ha a tranzakció bármelyik szakaszában hiba történik, rollback hajtódik végre és az adatok visszatérnek az eredeti állapotba.

A rollback mechanizmus az előreírási naplón (Write-Ahead Log, WAL) keresztül van megvalósítva. Mielőtt megváltoztatna egy adatoldalt, az ADB régi és új értéket ír a naplóba. Rollbackkor a rendszer olvassa a naplót és visszaállítja az eredeti értékeket az összes módosított oldalhoz. Ez garantálja, hogy áramszünet esetén is helyesen visszavonható a tranzakció.

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: részleges visszavonás

Hosszú tranzakciókban kényelmes a savepoint használata — köztes mentési pontok, amelyekhez visszatérhet anélkül, hogy befejezné a teljes tranzakciót. Ez lehetővé teszi a hibák kezelését egy összetett műveleten belül anélkül, hogy elveszítené a haladást annak más részeiben. A savepointot a legtöbb relációs ADB támogatja: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

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

ROLLBACK TO sp1;

Visszavonás telepítéskor: stratégiák és eszközök

Telepítés visszavonása — a működő alkalmazás visszaállítása az előző verzióra sikertelen telepítés után. Ez kritikus fontosságú képesség az éles környezet számára: a helyreállítási idő (MTTR) közvetlenül befolyásolja az SLA-t és a felhasználói élményt. A modern platformok az architektúrától és a rendelkezésre állási követelményektől függően több visszavonási stratégiát kínálnak.

Blue-green deployment

Blue-green — stratégia, ahol két azonos környezet működik egyszerre: blue (aktuális verzió) és green (új verzió). A forgalom a sikeres telepítés után a greenre irányítódik át. Ha az új verzió helytelenül működik, a forgalomkapcsoló visszatér a bluehoz. A visszavonás azonnal megtörténik, újratelepítés nélkül — elég megváltoztatni az útvonalválasztást.

Canary release automatikus visszavonással

Canary deployment a forgalom egy kis részét az új verzióra irányítja és figyeli a mérőszámokat: hibák száma, válaszidő, sikeres kérések aránya. Ha a mérőszámok romlanak, a rendszer automatikusan visszavonja a canaryt és az összes forgalmat a stabil verzióra irányítja. A Kubernetes és a service meshek (Istio, Linkerd) ezt a stratégiát készből támogatják.

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

Gyakorlati példák a visszavonásra a fejlesztésben

Nézzünk három tipikus forgatókönyvet, ahol a fejlesztőnek vissza kell vonnia változtatásokat. Minden forgatókönyv saját megközelítést igényel — az egyszerű terminálparancstól a CI/CD részvételével történő többlépéses eljárásig.

Forgatókönyv 1: véletlen commit a mainbe

Véletlenül egy hibás commitot küldött a mainbe. A feladata a változtatások visszavonása a csapat történetének elvesztése nélkül. Használja a git revert-et a visszavonó commit létrehozásához, majd git push. A csapat összes tagja látni fogja a visszavonás tényét és folytathatja a munkát konfliktusok nélkül. Ez a legbiztonságosabb és legátláthatóbb módszer.

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

Forgatókönyv 2: sikertelen adatbázis migráció

Az adatbázis migrációja hibával zárult és az adatok egy része megsérült. Használjon tranzakciós rollbacket a migrációs szkriptben és biztonsági mentésből történő helyreállítást a már alkalmazott változtatásokhoz. Egy jól megtervezett rendszerben minden migráció tranzakcióba van csomagolva — hiba esetén az ADB automatikusan rollbacket hajt végre.

Forgatókönyv 3: telepítés kritikus hibával

Az új verzió telepítése után észlelte, hogy a hitelesítés nem működik. Ha blue-green-t használ, a visszavonás az útválasztó visszakapcsolását jelenti. Ha rolling update — a kubectl rollout undo parancs visszaállítja az előző verziót. Ideális esetben a visszavonási folyamatnak automatizáltnak kell lennie és nem tarthat tovább egy perc nél.