Відкотити (Ролбек) у розробці: що це, способи та як працює

Що таке відкат і ролбек у розробці

Відкат (ролбек) — операція повернення системи до попереднього стабільного стану. У контексті розробки це може означати скасування коміту в 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 застосовують у shared-гілках: 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;

Відкат при деплої: стратегії та інструменти

Відкат деплою — повернення працюючого застосунку до попередньої версії після невдалого розгортання. Це критично важлива можливість для production-середовища: час відновлення (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, відкат — це перемикання router назад. Якщо rolling update — команда kubectl rollout undo поверне попередню версію. В ідеалі процес відкату має бути автоматизований і займати не більше хвилини.