Pagbabalik (Rollback) sa pag-develop: ano ito, mga paraan at paano ito gumagana

Ano ang pagbabalik at rollback sa pag-develop

Pagbabalik (rollback) — operasyon ng pagbalik ng system sa nakaraang stable na estado. Sa konteksto ng pag-develop, ito ay maaaring mangahulugan ng pagbawi ng commit sa Git, pagbalik ng transaksyon sa database, o pag-restore ng nakaraang bersyon ng application sa server. Ang termino ay nagmula sa Ingles na “rollback” at matatag na naka-embed sa vocabulary ng mga developer sa lahat ng platform.

Ang pangangailangan para sa pagbabalik ay lumitaw kapag ang isang bagong pagbabago ay sumisira ng functionality, nagdudulot ng mga error, o hindi pumasa sa quality check. Sa isang mahusay na organisadong proseso ng pag-develop, ang pagbabalik ay hindi tanda ng pagkabigo, kundi isang standard procedure na naka-embed sa workflow. Kung gaano kabilis ang team ay maaaring magbalik ng isang problematikong pagbabago, mas mababa ang epekto ng bug sa mga user.

Ang iba’t ibang kasangkapan ay nag-aalok ng iba’t ibang mekanismo ng pagbabalik: Ang Git ay nagbibigay ng pagpipilian sa pagitan ng ligtas na revert at mapanirang reset, ang mga database ay sumusuporta sa transactional rollback, at ang CI/CD system ay maaaring lumipat ng trapiko sa pagitan ng mga bersyon. Ang pagpili ng approach ay depende sa konteksto at mga kinakailangan para sa pagpapanatili ng history ng mga pagbabago.

Git revert vs git reset: ano ang pagkakaiba

Git revert — ligtas na paraan ng pagbabalik na gumagawa ng bagong commit na bumabalewala sa mga pagbabago ng nakaraang commit. Ang history ay nananatiling linear, lahat ng lumang commit ay pinapanatili. Ito ang tanging tamang pagpipilian para sa pagbabalik sa isang shared branch kung saan nagtatrabaho ang maraming developer. Ang command na git revert ay hindi nagtatanggal ng history — idinadagdag nito ang katotohanan ng pagbabalik bilang isang bagong pagbabago.

Git reset ay naglilipat ng pointer ng kasalukuyang branch sa tinukoy na commit, itinatapon ang lahat ng kasunod na pagbabago. Depende sa flag — soft, mixed, o hard — iba’t ibang pinoproseso ng reset ang working directory at index. Ang hard mode ay ganap na nag-aalis ng mga pagbabago mula sa history, na ginagawa itong mapanganib para sa shared branches at angkop lamang para sa lokal na trabaho.

Kailan gagamitin ang revert

Revert ay inilalapat sa shared branches: main, develop, release. Pinapanatili nito ang history at pinapayagan ang ibang developer na maunawaan na ang isang pagbabago ay binawi. Pagkatapos ng revert, ang git pull ay maaaring gawin nang ligtas — ang system ay hindi mag-generate ng mga conflict na nauugnay sa muling isinulat na history. Sa team work, ang revert ay ang default na standard.

# I-undo ang huling commit sa pamamagitan ng paggawa ng bagong commit
git revert HEAD

# I-undo ang isang partikular na commit sa pamamagitan ng hash
git revert a1b2c3d

Kailan gagamitin ang reset

Reset ay angkop sa isang lokal na branch kung saan hindi mo pa nai-publish ang mga pagbabago. Kung nag-eksperimento ka at nais mong ganap na linisin ang history — gagawin ito ng reset hard. Sa lokal na branch, maaari mong gamitin ang reset mixed upang i-undo ang mga commit ngunit panatilihin ang mga pagbabago sa working directory para sa muling pag-commit.

# I-undo ang huling commit, panatilihin ang mga pagbabago sa working directory
git reset HEAD~1

# Buong pag-undo — ang mga pagbabago ay permanenteng tinanggal
git reset --hard HEAD~2

Rollback sa mga database: transaksyon at ACID

Rollback ng transaksyon — operasyon na bumabalewala sa lahat ng pagbabagong ginawa sa loob ng kasalukuyang transaksyon at ibinabalik ang database sa estado sa sandali ng pagsisimula nito. Ito ay ginagarantiyahan ang atomicity — isa sa apat na prinsipyo ng ACID (Atomicity, Consistency, Isolation, Durability). Kung sa anumang yugto ng transaksyon ay may error, ang rollback ay isinasagawa at ang data ay bumalik sa orihinal na posisyon.

Ang mekanismo ng rollback ay ipinatupad sa pamamagitan ng write-ahead log (WAL). Bago baguhin ang isang data page, ang DBMS ay nagtatala ng luma at bagong halaga sa log. Sa rollback, binabasa ng system ang log at pinapanumbalik ang orihinal na mga halaga para sa lahat ng binagong page. Ginagarantiyahan nito na kahit sa kaso ng power failure, ang transaksyon ay maaaring mabawi nang tama.

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: bahagyang pagbabalik

Sa mahabang transaksyon, maginhawang gumamit ng savepoint — mga intermediate save point na maaaring balikan nang hindi tinatapos ang buong transaksyon. Ito ay nagpapahintulot sa paghawak ng mga error sa loob ng isang komplikadong operasyon nang hindi nawawala ang progreso sa ibang bahagi nito. Ang savepoint ay sinusuportahan ng karamihan ng relational DBMS: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

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

ROLLBACK TO sp1;

Pagbabalik sa deployment: mga estratehiya at kasangkapan

Pagbabalik ng deployment — pagbalik ng tumatakbong application sa nakaraang bersyon pagkatapos ng hindi matagumpay na deployment. Ito ay isang kritikal na kakayahan para sa production environment: ang oras ng pagbawi (MTTR) ay direktang nakakaapekto sa SLA at karanasan ng user. Ang mga modernong platform ay nag-aalok ng ilang estratehiya ng pagbabalik depende sa arkitektura at mga kinakailangan sa availability.

Blue-green deployment

Blue-green — estratehiya kung saan dalawang magkaparehong environment ang gumagana nang sabay: blue (kasalukuyang bersyon) at green (bagong bersyon). Ang trapiko ay inililipat sa green pagkatapos ng matagumpay na deployment. Kung ang bagong bersyon ay gumagana nang hindi tama, ang traffic switch ay babalik sa blue. Ang pagbabalik ay isinasagawa kaagad, nang walang muling pag-deploy — sapat na upang baguhin ang routing.

Canary release na may automatic rollback

Canary deployment ay nagdidirekta ng maliit na bahagi ng trapiko sa bagong bersyon at sinusubaybayan ang metrics: bilang ng mga error, oras ng pagtugon, porsyento ng mga matagumpay na kahilingan. Kung ang metrics ay lumala, ang system ay awtomatikong bumabalik ng canary at idinidirekta ang lahat ng trapiko sa stable na bersyon. Ang Kubernetes at service meshes (Istio, Linkerd) ay sumusuporta sa estratehiyang ito mula sa labas ng kahon.

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

Mga praktikal na halimbawa ng pagbabalik sa pag-develop

Tingnan natin ang tatlong tipikal na senaryo kung saan kailangang ibalik ng developer ang mga pagbabago. Ang bawat senaryo ay nangangailangan ng sarili nitong approach — mula sa simpleng command sa terminal hanggang sa multi-step procedure na may partisipasyon ng CI/CD.

Senaryo 1: aksidenteng commit sa main

Aksidente mong na-push ang isang commit na may bug sa main. Ang iyong gawain ay ibalik ang mga pagbabago nang hindi nawawala ang history para sa team. Gamitin ang git revert upang gumawa ng reversing commit at pagkatapos ay git push. Makikita ng lahat ng miyembro ng team ang katotohanan ng pagbabalik at maaaring magpatuloy sa trabaho nang walang conflicts. Ito ang pinakaligtas at pinaka-transparent na paraan.

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

Senaryo 2: hindi matagumpay na database migration

Ang database migration ay natapos na may error at ang bahagi ng data ay nasira. Gamitin ang transactional rollback sa migration script at pag-restore mula sa backup para sa mga pagbabagong na-apply na. Sa isang mahusay na dinisenyong sistema, ang bawat migration ay nakabalot sa isang transaksyon — sa error, awtomatikong nag-execute ng rollback ang DBMS.

Senaryo 3: deployment na may kritikal na bug

Pagkatapos ng deployment ng bagong bersyon, natuklasan mo na hindi gumagana ang authentication. Kung gumagamit ka ng blue-green, ang pagbabalik ay nangangahulugang paglipat ng router pabalik. Kung rolling update — ang command na kubectl rollout undo ay magbabalik ng nakaraang bersyon. Sa perpektong sitwasyon, ang proseso ng pagbabalik ay dapat awtomatiko at hindi tatagal ng higit sa isang minuto.