Blue-Green Deployment

النشر الأزرق-الأخضر Blue-Green Deployment

Blue-Green يشغّل بيئتين متطابقتين كاملتين، الإنتاج الحالي (Blue) والإصدار الجديد (Green)، ثم يحوّل كل حركة المرور دفعة واحدة بينهما بلا خليط إصدارات.

يُنشر الإصدار الجديد بالكامل على بيئة Green منفصلة تماماً عن بيئة Blue التي تخدم المستخدمين حالياً، ويُختبر Green بمعزل عن حركة المرور الحقيقية. عند التأكد من جاهزيته، تُحوَّل كل حركة المرور دفعة واحدة من Blue إلى Green — عادة بتبديل إعدادات موازن الحمل (Load Balancer) أو selector الخدمة، لا بإعادة نشر أي شيء.

الميزة الأساسية مقارنة بـ Rolling Update: لا يوجد أي لحظة يعمل فيها الإصدار القديم والجديد معاً أمام المستخدم، والتراجع فوري تماماً — يكفي إعادة التوجيه لـ Blue. الكلفة المقابلة موارد مضاعفة مؤقتاً، لأن بيئتين كاملتين تعملان جنباً إلى جنب حتى اكتمال التبديل.

الصياغة

# تبديل عبر selector الخدمة (مثال Kubernetes)
spec:
  selector:
    version: <blue | green>

📄 مثال

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    version: green   # كان blue قبل التبديل
  ports:
    - port: 80
      targetPort: 3000

أهم النقاط

العنصر	الوظيفة
بيئة Blue	الإصدار الحالي الذي يخدم كل حركة المرور قبل التبديل
بيئة Green	الإصدار الجديد المنشور كاملاً ويُختبر قبل استقبال حركة مرور حقيقية
تبديل الموازن/الـ selector	الخطوة التي تنقل كل حركة المرور دفعة واحدة من بيئة لأخرى
التراجع	إعادة الموازن أو selector إلى القيمة القديمة — فوري تماماً

💡 نصائح عملية

اختبر Green فعلياً بحركة مرور اصطناعية أو smoke tests قبل التبديل، لا تكتفِ بنجاح البناء فقط
احتفظ ببيئة Blue قائمة لفترة قصيرة بعد التبديل لضمان تراجع فوري إذا ظهرت مشكلة لم تُكتشف بالاختبار

⚠️ أخطاء شائعة

حذف بيئة Blue فور التبديل مباشرة، فيصبح التراجع السريع (الميزة الأساسية لهذه الاستراتيجية) غير ممكن
تجاهل مشاركة قاعدة البيانات بين البيئتين — تغييرات مخطط (schema) غير متوافقة مع الإصدارين معاً تكسر إحدى البيئتين

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار DEVOPS الكامل بالعربي.

📚 للتعمق التقني الكامل بالإنجليزية: MDN Web Docs