Vrácení (Rollback) ve vývoji: co to je, způsoby a jak to funguje

Co je vrácení a rollback ve vývoji

Vrácení (rollback) — operace návratu systému k předchozímu stabilnímu stavu. V kontextu vývoje to může znamenat zrušení commitu v Gitu, vrácení transakce v databázi nebo obnovení předchozí verze aplikace na serveru. Termín pochází z anglického „rollback“ a pevně se zakořenil ve slovníku vývojářů všech platforem.

Potřeba vrácení vzniká, když nová změna láme funkčnost, způsobuje chyby nebo neprojde kontrolou kvality. V dobře organizovaném vývojovém procesu není vrácení známkou neúspěchu, ale standardním postupem zabudovaným do pracovního toku. Čím rychleji může tým vrátit problematickou změnu, tím nižší je dopad chyby na uživatele.

Různé nástroje nabízejí různé mechanismy vrácení: Git dává volbu mezi bezpečným revert a destruktivním reset, databáze podporují transakční rollback a CI/CD systémy dokážou přepínat provoz mezi verzemi. Výběr přístupu závisí na kontextu a požadavcích na zachování historie změn.

Git revert vs git reset: v čem je rozdíl

Git revert — bezpečný způsob vrácení, který vytváří nový commit rušící změny předchozího. Historie zůstává lineární, všechny staré commity jsou zachovány. To je jediná správná volba pro vrácení ve společné větvi, na které pracuje více vývojářů. Příkaz git revert neodstraňuje historii — přidává fakt vrácení jako novou změnu.

Git reset přesouvá ukazatel aktuální větve na uvedený commit a zahazuje všechny následné změny. V závislosti na příznaku — soft, mixed nebo hard — reset jinak zpracovává pracovní adresář a index. Režim hard zcela odstraňuje změny z historie, což jej činí nebezpečným pro sdílené větve a vhodným pouze pro místní práci.

Kdy použít revert

Revert se aplikuje ve sdílených větvích: main, develop, release. Zachovává historii a umožňuje ostatním vývojářům pochopit, že změna byla zrušena. Po revertu lze bezpečně provést git pull — systém nevygeneruje konflikty související s přepsanou historií. V týmové práci je revert výchozím standardem.

# Zrušit poslední commit vytvořením nového commitu
git revert HEAD

# Zrušit konkrétní commit podle hashe
git revert a1b2c3d

Kdy použít reset

Reset je vhodný v místní větvi, kde jste ještě nezveřejnili změny. Pokud jste experimentovali a chcete zcela vyčistit historii — reset hard to udělá. V místní větvi můžete použít reset mixed ke zrušení commitů, ale zachování změn v pracovním adresáři pro opětovný commit.

# Zrušit poslední commit, ponechat změny v pracovním adresáři
git reset HEAD~1

# Úplné zrušení — změny jsou trvale odstraněny
git reset --hard HEAD~2

Rollback v databázích: transakce a ACID

Rollback transakce — operace rušící všechny změny provedené v rámci aktuální transakce a vracející databázi do stavu na počátku. To zaručuje atomicitu — jeden ze čtyř principů ACID (Atomicity, Consistency, Isolation, Durability). Pokud v jakékoli fázi transakce dojde k chybě, provede se rollback a data se vrátí do původního stavu.

Mechanismus rollback je implementován prostřednictvím protokolu s předzápisem (Write-Ahead Log, WAL). Před změnou datové stránky zapíše SŘBD starou a novou hodnotu do protokolu. Při rollbacku systém čte protokol a obnovuje původní hodnoty pro všechny změněné stránky. To zaručuje, že i při výpadku napájení může být transakce správně zrušena.

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: částečné vrácení

V dlouhých transakcích je vhodné používat savepoint — průmežné body uložení, ke kterým se lze vrátit bez ukončení celé transakce. To umožňuje zpracování chyb uvnitř složité operace bez ztráty pokroku v ostatních jejích částech. Savepoint je podporován většinou relačních SŘBD: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

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

ROLLBACK TO sp1;

Vrácení při nasazení: strategie a nástroje

Vrácení nasazení — návrat fungující aplikace k předchozí verzi po neúspěšném nasazení. To je kriticky důležitá schopnost pro produkční prostředí: doba obnovy (MTTR) přímo ovlivňuje SLA a uživatelskou zkušenost. Moderní platformy nabízejí několik strategií vrácení v závislosti na architektuře a požadavcích na dostupnost.

Blue-green deployment

Blue-green — strategie, při které současně pracují dvě identická prostředí: blue (aktuální verze) a green (nová verze). Provoz je přepnut na green po úspěšném nasazení. Pokud nová verze pracuje nesprávně, přepínač provozu se vrátí na blue. Vrácení se provádí okamžitě, bez opětovného nasazení — stačí změnit směrování.

Canary release s automatickým vrácením

Canary deployment směruje malou část provozu na novou verzi a sleduje metriky: počet chyb, dobu odezvy, procento úspěšných požadavků. Pokud se metriky zhorší, systém automaticky vrátí canary a nasměruje veškerý provoz na stabilní verzi. Kubernetes a service meshe (Istio, Linkerd) podporují tuto strategii ihned po vybalení.

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

Praktické příklady vrácení ve vývoji

Uvažujme tři typické scénáře, ve kterých vývojář potřebuje vrátit změny. Každý scénář vyžaduje vlastní přístup — od jednoduchého příkazu v terminálu po vícekrokový postup s účastí CI/CD.

Scénář 1: náhodný commit do main

Omylem jste odeslali commit s chybou do main. Vaším úkolem je vrátit změny bez ztráty historie pro tým. Použijte git revert k vytvoření vracejícího commitu a poté git push. Všichni členové týmu uvidí fakt vrácení a budou moci pokračovat v práci bez konfliktů. Toto je nejbezpečnější a nejtransparentnější způsob.

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

Scénář 2: neúspěšná migrace databáze

Migrace databáze skončila chybou a část dat byla poškozena. Použijte transakční rollback v migračním skriptu a obnovení ze zálohy pro již aplikované změny. V dobře navrženém systému je každá migrace zabalena do transakce — při chybě SŘBD automaticky provede rollback.

Scénář 3: nasazení s kritickou chybou

Po nasazení nové verze jste zjistili, že autentizace nefunguje. Pokud používáte blue-green, vrácení znamená přepnutí routeru zpět. Pokud rolling update — příkaz kubectl rollout undo vrátí předchozí verzi. V ideálním případě by měl být proces vrácení automatizován a neměl by trvat déle než minutu.