التراجع (الرولباك) في التطوير: ما هو، الطرق وكيف يعمل

ما هو التراجع والرولباك في التطوير

التراجع (الرولباك) — عملية إعادة النظام إلى حالة مستقرة سابقة. في سياق التطوير، يمكن أن يعني ذلك إلغاء commit في Git، أو التراجع عن معاملة في قاعدة البيانات، أو العودة إلى إصدار سابق من التطبيق على الخادم. المصطلح مشتق من الإنجليزية «rollback» وهو راسخ بقوة في قاموس المطورين عبر جميع المنصات.

تنشأ الحاجة إلى التراجع عندما يكسر التغيير الجديد الوظائف أو يسبب أخطاء أو يفشل في فحوصات الجودة. في عملية التطوير المنظمة جيدًا، التراجع ليس علامة فشل، بل إجراء قياسي مدمج في سير العمل. كلما أسرع الفريق في التراجع عن تغيير إشكالي، قل تأثير الخلل على المستخدمين.

توفر الأدوات المختلفة آليات تراجع مختلفة: يقدم Git خيارًا بين revert الآمن و reset المدمر، وتدعم قواعد البيانات الرولباك المتعلق بالمعاملات، ويمكن لأنظمة CI/CD تبديل حركة المرور بين الإصدارات. يعتمد اختيار النهج على السياق ومتطلبات الحفاظ على تاريخ التغييرات.

Git revert vs git reset: ما الفرق

Git revert — طريقة آمنة للتراجع تنشئ commit جديدًا يلغي تغييرات الـcommit السابق. يبقى التاريخ خطيًا ويتم الاحتفاظ بجميع الـcommits القديمة. هذا هو الخيار الصحيح الوحيد للتراجع في فرع مشترك يعمل عليه عدة مطورين. 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 لإلغاء الـcommits ولكن الاحتفاظ بالتغييرات في دليل العمل لإعادة الـcommit.

# التراجع عن آخر commit، الاحتفاظ بالتغييرات في دليل العمل
git reset HEAD~1

# تراجع كامل — التغييرات تتم إزالتها بشكل دائم
git reset --hard HEAD~2

الرولباك في قواعد البيانات: المعاملات و ACID

الرولباك في المعاملة — عملية تلغي جميع التغييرات التي تم إجراؤها ضمن المعاملة الحالية وتعيد قاعدة البيانات إلى الحالة التي كانت عليها عند بدء المعاملة. هذا يضمن الذرية — أحد مبادئ ACID الأربعة (Atomicity, Consistency, Isolation, Durability). إذا حدث خطأ في أي مرحلة من المعاملة، يتم تنفيذ الرولباك وتعود البيانات إلى حالتها الأصلية.

يتم تنفيذ آلية الرولباك من خلال سجل الكتابة المسبقة (Write-Ahead Log, WAL). قبل تعديل صفحة بيانات، يكتب نظام إدارة قواعد البيانات القيم القديمة والجديدة في السجل. أثناء الرولباك، يقرأ النظام السجل ويستعيد القيم الأصلية لجميع الصفحات المعدلة. يضمن هذا أنه حتى في حالة انقطاع التيار الكهربائي، يمكن التراجع عن المعاملة بشكل صحيح.

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: commit عرضي في main

قمت بدفع commit به خطأ إلى main عن طريق الخطأ. مهمتك هي التراجع عن التغييرات دون فقدان التاريخ للفريق. استخدم git revert لإنشاء commit تراجع ثم git push. سيرى جميع أعضاء الفريق التراجع ويمكنهم مواصلة العمل دون تعارضات. هذه هي الطريقة الأكثر أمانًا وشفافية.

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

السيناريو 2: ترحيل قاعدة بيانات فاشل

فشل ترحيل قاعدة البيانات وتلفت بعض البيانات. استخدم الرولباك المتعلق بالمعاملات في سكريبت الترحيل والاستعادة من النسخة الاحتياطية للتغييرات المطبقة بالفعل. في النظام المصمم جيدًا، كل ترحيل مغلف في معاملة — عند حدوث خطأ، يقوم نظام إدارة قواعد البيانات تلقائيًا بتنفيذ الرولباك.

السيناريو 3: نشر مع خطأ حرج

بعد نشر إصدار جديد، تكتشف أن المصادقة لا تعمل. إذا كنت تستخدم blue-green، فالتراجع هو تحويل جهاز التوجيه مرة أخرى. إذا كان التحديث المتداول — أمر kubectl rollout undo سيعيد الإصدار السابق. من الناحية المثالية، يجب أن تكون عملية التراجع مؤتمتة وألا تستغرق أكثر من دقيقة.