ڈویلپمنٹ میں رول بیک: یہ کیا ہے، طریقے اور یہ کیسے کام کرتا ہے

ڈویلپمنٹ میں رول بیک کیا ہے

رول بیک ایک عمل ہے جو سسٹم کو پچھلی مستحکم حالت میں واپس لاتا ہے۔ ڈویلپمنٹ کے سیاق و سباق میں، اس کا مطلب 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 عمل میں آتا ہے اور ڈیٹا اپنی اصل حالت میں واپس آجاتا ہے۔

رول بیک میکانزم پہلے سے لکھے جانے والے لاگ (WAL) کے ذریعے نافذ کیا جاتا ہے۔ ڈیٹا پیج کو تبدیل کرنے سے پہلے، DBMS پرانی اور نئی قدریں لاگ میں لکھتا ہے۔ رول بیک کے دوران، سسٹم لاگ پڑھتا ہے اور تبدیل شدہ تمام پیجز کے لیے اصل قدریں بحال کرتا ہے۔ یہ یقینی بناتا ہے کہ بجلی کی بندش کی صورت میں بھی، لین دین کو صحیح طریقے سے واپس لیا جا سکے۔

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: جزوی رول بیک

لمبے لین دین میں، savepoint استعمال کرنا آسان ہے — درمیانی محفوظ کرنے کے مقامات جہاں پورے لین دین کو مکمل کیے بغیر واپس جایا جا سکتا ہے۔ یہ ایک پیچیدہ عمل کے اندر غلطیوں کو سنبھالنے کی اجازت دیتا ہے، اس کے دیگر حصوں میں پیش رفت کو کھونے کے بغیر۔ Savepoint زیادہ تر رشتہ دار DBMSs کے ذریعے سپورٹ کیا جاتا ہے: PostgreSQL، MySQL، Oracle۔

SAVEPOINT sp1;

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

ROLLBACK TO sp1;

ڈپلائمنٹ میں رول بیک: حکمت عملی اور اوزار

ڈپلائمنٹ رول بیک — ناکام ڈپلائمنٹ کے بعد چلتی ہوئی ایپلیکیشن کو پچھلے ورژن پر واپس لانا۔ یہ پروڈکشن ماحول کے لیے ایک اہم صلاحیت ہے: بحالی کا وقت (MTTR) براہ راست SLA اور صارف کے تجربے کو متاثر کرتا ہے۔ جدید پلیٹ فارم فن تعمیر اور دستیابی کی ضروریات کے لحاظ سے کئی رول بیک حکمت عملی پیش کرتے ہیں۔

Blue-green ڈپلائمنٹ

Blue-green ایک حکمت عملی ہے جس میں دو ایک جیسے ماحول بیک وقت چلتے ہیں: blue (موجودہ ورژن) اور green (نیا ورژن)۔ کامیاب ڈپلائمنٹ کے بعد ٹریفک green پر منتقل ہو جاتی ہے۔ اگر نیا ورژن غلط طریقے سے کام کرتا ہے، تو ٹریفک سوئچ blue پر واپس آ جاتا ہے۔ رول بیک فوری طور پر کیا جاتا ہے، دوبارہ ڈپلائمنٹ کے بغیر — صرف روٹنگ تبدیل کریں۔

خودکار رول بیک کے ساتھ Canary ریلیز

Canary ڈپلائمنٹ ٹریفک کا ایک چھوٹا حصہ نئے ورژن پر بھیجتا ہے اور میٹرکس کی نگرانی کرتا ہے: غلطی کی شرح، جوابی وقت، کامیاب درخواستوں کا فیصد۔ اگر میٹرکس خراب ہوتے ہیں، تو سسٹم خود بخود 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 استعمال کریں اور پہلے سے لاگو تبدیلیوں کے لیے بیک اپ سے بحال کریں۔ ایک اچھی طرح سے ڈیزائن کردہ سسٹم میں، ہر مائیگریشن ایک لین دین میں لپیٹی جاتی ہے — غلطی پر، DBMS خود بخود rollback کرتا ہے۔

منظرنامہ 3: سنگین بگ کے ساتھ ڈپلائمنٹ

نیا ورژن ڈپلائے کرنے کے بعد، آپ کو پتہ چلتا ہے کہ تصدیق کام نہیں کر رہی۔ اگر آپ blue-green استعمال کرتے ہیں، تو رول بیک روٹر کو واپس تبدیل کرنا ہے۔ اگر رولنگ اپڈیٹ ہے — kubectl rollout undo کمانڈ پچھلا ورژن واپس لائے گا۔ مثالی طور پر، رول بیک کا عمل خودکار ہونا چاہیے اور ایک منٹ سے زیادہ نہیں لینا چاہیے۔