بازگشت (Rollback) در توسعه: چیست، روش‌ها و چگونه کار می‌کند

بازگشت و رول‌بک در توسعه چیست

بازگشت (رول‌بک) — عملیات بازگرداندن سیستم به وضعیت پایدار قبلی. در زمینه توسعه، این می‌تواند به معنای لغو commit در Git، بازگرداندن تراکنش در پایگاه داده یا بازگرداندن نسخه قبلی برنامه روی سرور باشد. این اصطلاح از انگلیسی «rollback» گرفته شده و در فرهنگ لغت توسعه‌دهندگان تمام پلتفرم‌ها تثبیت شده است.

نیاز به بازگشت زمانی ایجاد می‌شود که تغییر جدید عملکرد را خراب می‌کند، باعث خطا می‌شود یا از بررسی کیفیت عبور نمی‌کند. در یک فرآیند توسعه خوب سازمان‌دهی شده، بازگشت نشانه شکست نیست، بلکه یک رویه استاندارد تعبیه شده در جریان کار است. هرچه تیم سریع‌تر بتواند یک تغییر مشکل‌ساز را بازگرداند، تاثیر باگ بر کاربران کمتر است.

ابزارهای مختلف مکانیزم‌های بازگشت متفاوتی ارائه می‌دهند: Git بین revert ایمن و reset مخرب انتخاب می‌دهد، پایگاه‌های داده از rollback تراکنشی پشتیبانی می‌کنند و سیستم‌های CI/CD می‌توانند ترافیک را بین نسخه‌ها جابجا کنند. انتخاب رویکرد به زمینه و الزامات حفظ تاریخچه تغییرات بستگی دارد.

Git revert در مقابل git reset: تفاوت چیست

Git revert — روش ایمن بازگشت که یک commit جدید ایجاد می‌کند و تغییرات قبلی را لغو می‌کند. تاریخچه خطی باقی می‌ماند، تمام commitهای قدیمی حفظ می‌شوند. این تنها انتخاب صحیح برای بازگشت در شاخه مشترکی است که چندین توسعه‌دهنده روی آن کار می‌کنند. دستور git revert تاریخچه را حذف نمی‌کند — بلکه واقعیت بازگشت را به عنوان یک تغییر جدید اضافه می‌کند.

Git reset اشاره‌گر شاخه فعلی را به یک commit مشخص منتقل می‌کند و تمام تغییرات بعدی را کنار می‌گذارد. بسته به پرچم — soft، mixed یا hard — reset دایرکتوری کاری و ایندکس را متفاوت مدیریت می‌کند. حالت hard تغییرات را به طور کامل از تاریخچه حذف می‌کند، که آن را برای شاخه‌های مشترک خطرناک و فقط برای کار محلی مناسب می‌کند.

چه زمانی از revert استفاده کنیم

Revert در شاخه‌های اشتراکی استفاده می‌شود: main، develop، release. تاریخچه را حفظ می‌کند و به سایر توسعه‌دهندگان اجازه می‌دهد بفهمند که یک تغییر لغو شده است. پس از revert می‌توان با خیال راحت git pull انجام داد — سیستم تضادهای مربوط به تاریخچه بازنویسی شده را ایجاد نخواهد کرد. در کار تیمی، revert استاندارد پیش‌فرض است.

# لغو آخرین commit با ایجاد یک commit جدید
git revert HEAD

# لغو یک commit خاص با هش
git revert a1b2c3d

چه زمانی از reset استفاده کنیم

Reset در شاخه محلی که هنوز تغییرات را منتشر نکرده‌اید مناسب است. اگر آزمایش کرده‌اید و می‌خواهید تاریخچه را کاملاً پاک کنید — reset hard این کار را انجام می‌دهد. در شاخه محلی می‌توانید از reset mixed استفاده کنید تا commitها را لغو کنید اما تغییرات را در دایرکتوری کاری برای commit مجدد حفظ کنید.

# لغو آخرین commit، حفظ تغییرات در دایرکتوری کاری
git reset HEAD~1

# لغو کامل — تغییرات به طور دائمی حذف می‌شوند
git reset --hard HEAD~2

رول‌بک در پایگاه‌های داده: تراکنش‌ها و ACID

رول‌بک تراکنش — عملیاتی که تمام تغییرات انجام شده در چارچوب تراکنش جاری را لغو کرده و پایگاه داده را به وضعیت ابتدای آن بازمی‌گرداند. این اتمیسیته را تضمین می‌کند — یکی از چهار اصل ACID (Atomicity, Consistency, Isolation, Durability). اگر در هر مرحله‌ای از تراکنش خطایی رخ دهد، rollback اجرا شده و داده‌ها به وضعیت اولیه بازمی‌گردند.

مکانیزم rollback از طریق ثبت پیش‌نویس (Write-Ahead Log, WAL) پیاده‌سازی می‌شود. قبل از تغییر صفحه داده، DBMS مقدار قدیم و جدید را در لاگ ثبت می‌کند. هنگام rollback، سیستم لاگ را خوانده و مقادیر اصلی را برای تمام صفحات تغییر یافته بازیابی می‌کند. این تضمین می‌کند که حتی در صورت قطع برق، تراکنش می‌تواند به درستی لغو شود.

BEGIN TRANSACTION;

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

-- Rollback on error
ROLLBACK;

Savepoint: بازگشت جزئی

در تراکنش‌های طولانی، استفاده از savepoint — نقاط ذخیره میانی که می‌توان بدون پایان دادن به کل تراکنش به آنها بازگشت کرد — راحت است. این امکان مدیریت خطاها درون یک عملیات پیچیده را بدون از دست دادن پیشرفت در سایر بخش‌های آن فراهم می‌کند. Savepoint توسط اکثر DBMSهای رابطه‌ای پشتیبانی می‌شود: 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 و service meshها (Istio، Linkerd) از این استراتژی به صورت پیش‌فرض پشتیبانی می‌کنند.

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

مثال‌های عملی بازگشت در توسعه

سه سناریوی معمولی را در نظر می‌گیریم که در آنها توسعه‌دهنده باید تغییرات را بازگرداند. هر سناریو رویکرد خود را می‌طلبد — از یک دستور ساده در ترمینال تا یک رویه چندمرحله‌ای با مشارکت CI/CD.

سناریوی 1: commit تصادفی در main

شما به طور تصادفی یک commit با باگ به main فرستاده‌اید. وظیفه شما بازگرداندن تغییرات بدون از دست دادن تاریخچه برای تیم است. از git revert برای ایجاد commit لغوکننده استفاده کنید و سپس git push. تمام اعضای تیم واقعیت بازگشت را خواهند دید و می‌توانند بدون تضاد به کار ادامه دهند. این امن‌ترین و شفاف‌ترین روش است.

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

سناریوی 2: مهاجرت ناموفق پایگاه داده

مهاجرت پایگاه داده با خطا به پایان رسید و بخشی از داده‌ها آسیب دید. از rollback تراکنشی در اسکریپت مهاجرت و بازیابی از پشتیبان برای تغییرات اعمال شده استفاده کنید. در یک سیستم خوب طراحی شده، هر مهاجرت در یک تراکنش پیچیده می‌شود — در صورت خطا، DBMS به طور خودکار rollback را انجام می‌دهد.

سناریوی 3: استقرار با باگ بحرانی

پس از استقرار نسخه جدید، متوجه شده‌اید که احراز هویت کار نمی‌کند. اگر از blue-green استفاده می‌کنید، بازگشت به معنای برگرداندن راوتر است. اگر rolling update — دستور kubectl rollout undo نسخه قبلی را بازمی‌گرداند. در حالت ایدهال، فرآیند بازگشت باید خودکار باشد و بیش از یک دقیقه طول نکشد.