Откачивање (Rollback) у развоју: шта је, начини и како ради

Шта је откачивање и ролбек у развоју

Откачивање (ролбек) — операција враћања система на претходно стабилно стање. У контексту развоја, ово може значити поништавање комита у Git-у, враћање трансакције у бази података или враћање претходне верзије апликације на серверу. Термин потиче из енглеског „rollback” и чврсто се укоренио у речнику програмера свих платформи.

Потреба за враћањем настаје када нова измена ломи функционалност, изазива грешке или не пролази проверу квалитета. У добро организованом развојном процесу, враћање није знак неуспеха, већ стандардна процедура уграђена у радни ток. Што брже тим може да врати проблематичну измену, мањи је утицај бага на кориснике.

Различити алати нуде различите механизме враћања: Git даје избор између безбедног revert и деструктивног reset, базе података подржавају трансакциони rollback, а CI/CD системи могу да пребацују саобраћај између верзија. Избор приступа зависи од контекста и захтева за очувањем историје измена.

Git revert vs git reset: у чему је разлика

Git revert — безбедан начин враћања који креира нови комит који поништава измене претходног. Историја остаје линеарна, сви стари комити се чувају. Ово је једини правилан избор за враћање у заједничкој грани на којој ради више програмера. Команда git revert не брише историју — она додаје чињеницу враћања као нову измену.

Git reset помера показивач текуће гране на наведени комит, одбацујући све касније измене. У зависности од заставице — soft, mixed или hard — reset различито обрађује радни директоријум и индекс. Hard режим потпуно уклања измене из историје, што га чини опасним за заједничке гране и погодним само за локални рад.

Када користити revert

Revert се примењује у дељеним гранама: main, develop, release. Чува историју и омогућава другим програмерима да разумеју да је измена поништена. Након revert-а може се безбедно урадити git pull — систем неће генерисати конфликте повезане са преписано историјом. У тимском раду, revert је подразумевани стандард.

# Поништи последњи комит креирањем новог комита
git revert HEAD

# Поништи одређени комит по хешу
git revert a1b2c3d

Када користити reset

Reset је прикладан у локалној грани где још нисте објавили измене. Ако сте експериментисали и желите потпуно да очистите историју — reset hard ће то учинити. У локалној грани можете користити reset mixed да поништите комите, али сачувате измене у радном директоријуму за поновни комит.

# Поништи последњи комит, задржи измене у радном директоријуму
git reset HEAD~1

# Потпуно поништавање — измене су трајно уклоњене
git reset --hard HEAD~2

Ролбек у базама података: трансакције и ACID

Ролбек трансакције — операција која поништава све измене направљене у оквиру текуће трансакције и враћа базу података у стање на тренутак њеног почетка. Ово гарантује атомичност — један од четири принципа ACID (Atomicity, Consistency, Isolation, Durability). Ако у било којој фази трансакције дође до грешке, извршава се rollback и подаци се враћају на првобитно стање.

Механизам rollback-а је имплементиран кроз дневник претходног уписа (Write-Ahead Log, WAL). Пре него што измени страницу података, СУБП уписује стару и нову вредност у дневник. Приликом rollback-а, систем чита дневник и обнавља оригиналне вредности за све измењене странице. Ово гарантује да чак и у случају нестанка струје трансакција може бити исправно поништена.

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: делимично враћање

У дугим трансакцијама згодно је користити savepoint — међутачке чувања на које се можете вратити без завршавања целе трансакције. Ово омогућава обраду грешака унутар сложене операције без губљења напретка у другим њеним деловима. Savepoint подржава већина релационих СУБП-а: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

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

ROLLBACK TO sp1;

Враћање при имплементацији: стратегије и алати

Враћање имплементације — враћање радеће апликације на претходну верзију након неуспешне имплементације. Ово је критично важна могућност за продукционо окружење: време опоравка (MTTR) директно утиче на SLA и корисничко искуство. Модерне платформе нуде неколико стратегија враћања у зависности од архитектуре и захтева за доступношћу.

Blue-green deployment

Blue-green — стратегија у којој истовремено раде два идентична окружења: blue (тренутна верзија) и green (нова верзија). Саобраћај се преусмерава на green након успешне имплементације. Ако нова верзија ради неисправно, прекидач саобраћаја се враћа на blue. Враћање се извршава тренутно, без поновне имплементације — довољно је променити рутирање.

Canary release са аутоматским враћањем

Canary deployment усмерава мали део саобраћаја на нову верзију и прати метрике: број грешака, време одговора, проценат успешних захтева. Ако се метрике погоршају, систем аутоматски враћа canary и усмерава сав саобраћај на стабилну верзију. Kubernetes и сервис-мешеви (Istio, Linkerd) подржавају ову стратегију из кутије.

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

Практични примери враћања у развоју

Размотримо три типична сценарија у којима програмер треба да врати измене. Сваки сценарио захтева свој приступ — од једноставне команде у терминалу до процедуре у више корака са учешћем CI/CD.

Сценарио 1: случајни комит у main

Случајно сте послали комит са багом у main. Ваш задатак је да вратите измене без губитка историје за тим. Користите git revert за креирање поништавајућег комита, а затим git push. Сви чланови тима ће видети чињеницу враћања и моћи ће да наставе рад без конфликата. Ово је најсигурнији и најтранспарентнији начин.

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

Сценарио 2: неуспешна миграција базе података

Миграција базе података завршена је грешком и део података је оштећен. Користите трансакциони rollback у миграционом скрипту и обнављање из бекапа за већ примењене измене. У добро дизајнираном систему свака миграција је умотана у трансакцију — при грешци СУБП аутоматски извршава rollback.

Сценарио 3: имплементација са критичним багом

Након имплементације нове верзије, открили сте да ауторизација не ради. Ако користите blue-green, враћање је пребацивање рутера назад. Ако rolling update — команда kubectl rollout undo ће вратити претходну верзију. У идеалном случају процес враћања треба да буде аутоматизован и да не траје дуже од минута.