ما المقصود بالنشر بنظام الأزرق-الأخضر؟

هناك بيئة واحدة فعالة تخدم المستخدمين وتُسمى البيئة "الزرقاء"، بينما تُستخدم البيئة الأخرى "الخضراء" لنشر الإصدار الجديد واختباره. عند الموافقة على الإصدار الجديد، يتم توجيه حركة البيانات فوراً من البيئة الزرقاء إلى البيئة الخضراء.

تم نشر وتسمية هذه الاستراتيجية من قِبل Jez Humble و David Farley في كتابهما الرائد الصادر عام 2010 بعنوان: التسليم المستمر: إصدارات برمجية موثوقة من خلال أتمتة البناء والاختبار والنشر.

تقنية الأزرق-الأخضر (Blue-Green) هي تقنية نشر مستمر تسمح بالقضاء على فترات التعطل، والقدرة على استرجاع النسخة القديمة فوراً. فهي تتيح إجراء اختبارات A/B بكل سهولة، كما توفر بيئة تطوير آمنة تمنع وصول المستخدمين النهائيين إلى إصدارات غير جاهزة.

وعلى الرغم من أن صياغة "الأزرق والأخضر" هي الأكثر شيوعاً، إلا أن هناك تنويعات أخرى. تستخدم Netflix "الأحمر والأسود"، لكن المفهوم يظل كما هو. في بعض الأحيان، قد يرغب المطورون في الحصول على أكثر من بيئتين. يُعد مخطط تسمية الألوان فعالاً للتمييز بين بيئتين. ومع ذلك، قد تستخدم المؤسسات أيضًا اصطلاحات تسمية مثل أرقام الإصدارات أو مُعرفات البناء أو العناوين المخصصة، لا سيما إذا كان هناك أكثر من بيئتين معنيتين.

على الرغم من بساطة المفهوم، إلا أن هناك عدة خطوات ومتغيرات ضمن تلك الخطوات لإنشاء نشر أزرق-أخضر مستقر وآمن يستفيد من مزايا هذه الاستراتيجية.

يمكن تحقيق إنشاء بيئات متطابقة للنشر بنظام الأزرق-الأخضر إما يدويًا أو باستخدام أدوات مؤتمتة. البنية التحتية كرمز، أو IaC، هي أحد الأساليب المؤتمتة للتزويد. تستخدم IaC ملفات تهيئة قابلة للقراءة آلياً، وهي تشبه إلى حد ما مجموعة من التعليمات أو الوصفة لتمكين التجهيز والتهيئة التلقائيين للبنية التحتية لتكنولوجيا المعلومات وفقاً لمواصفات محددة مسبقاً.

تمكّن IaC المطورين من تشغيل نسخة من البيئة الزرقاء تلقائيًا، والتي تعمل بالفعل، لاستخدامها كبيئة خضراء. يمكن للمطورين بعد ذلك تعديل هذه القوالب حسب الحاجة، مع اليقين بأنهم يبدؤون من أساس موثوق. يساعد استخدام IaC في ضمان تكرار عمليات النسخ بدقة وإحكام.

يُعد استخدام النقل بالحاويات نهجاً تقنياً آخر، حيث يتم فيه تجميع كود التطبيق والتبعيات وواجهات برمجة التطبيقات معاً في "صورة حاوية" واحدة. يضمن استخدام الحاويات أن البيئة بأكملها متطابقة. Kubernetes، هي منصة مفتوحة المصدر لتنسيق الحاويات، تُستخدم عادة في عمليات النقل بالحاويات ضمن عملية النشر بنظام الأزرق-الأخضر.

بعد إنشاء البيئات، يتم نشر التطبيق على البيئة الزرقاء (المباشرة).

يُعد موازن التحميل آلية، غالباً ما توجد أمام بيئات التطبيقات كأداة ضمن مزودي خدمات السحابة أو بيئات Kubernetes، حيث يعمل على توجيه حركة مرور الإنتاج حسب الرغبة. في هذا السيناريو، يوجه موازن التحميل حركة المرور إلى البيئة الزرقاء المباشرة.

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

عند اكتمال عملية النشر في البيئة الخضراء، قم بإجراء جميع خطوات التحقق اللازمة. قد تشمل هذه الخطوات فحوصات أمنية، واختبارات للأداء، وعمليات فحص للأخطاء، وغيرها.

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

سيكون هذا التحول فوريًا ؛ لن يرى المستخدمون في أي وقت خطأ أو أي شيء آخر غير البيئات الزرقاء أو الخضراء.

يمكن استخدام تحديثات نظام أسماء النطاقات (DNS) لتوجيه المستخدمين إلى البيئة المطلوبة، ولكن قد يحدث تأخير كبير بسبب استغراق ذاكرة التخزين المؤقت وقتًا لتحديث عنوان IP. نظرًا لهذه المخاوف، يُفضل استخدام موازنات التحميل لأن التحديثات تدخل حيز التنفيذ على الفور.

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

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

إيقاف تشغيل البيئة الزرقاء غير المستخدمة أمر اختياري؛ فقد ترغب بعض المؤسسات في الاحتفاظ ببيئة زرقاء إلى أجل غير مسمى، وذلك في حال دعت الحاجة للتراجع إلى البيئة الخضراء في أي وقت. ولكن هناك أيضاً أسباب تتعلق بالتكلفة قد تدعو إلى إيقاف تشغيل البيئة الزرقاء من الخدمة في مرحلة ما من دورة حياتها. وبدلاً من ذلك، يمكن أن تصبح البيئة الزرقاء هي البيئة التجريبية التالية، أو الخضراء.

إنّ مسار التكامل المستمر والتسليم المستمر (CI/CD) هو عبارة عن سير عمل عمليات التطوير مؤتمت يعمل على تبسيط عملية تسليم البرمجيات. يسهل هذا المسار التسليم المستمر لتغييرات الأكواد في التطبيقات.

إنها ممارسة متكاملة بشكل وثيق مع النشر بنظام الأزرق-الأخضر: حيث يُمكّن التكامل المستمر والتسليم المستمر (CI/CD) هذا النوع من النشر، وغالباً ما يتم دمج عمليات النشر بطريقة الأزرق-الأخضر ضمن مسارات (CI/CD) للمساعدة في إصدار تحديثات البرمجيات دون أي توقف عن العمل وبأقل قدر من المخاطر.

تقوم مسارات التكامل المستمر (CI) باختبار ودمج الأكواد البرمجية الجديدة تلقائيًا قبل دمجها في المستودع المركزي، مما يقلل من مخاطر وصول الأكواد المعيبة إلى مرحلة النشر. تعتمد مسارات التسليم المستمر (CD) على استراتيجية النشر بنظام الأزرق-الأخضر لتحسين الإصدارات السريعة دون التأثير على المستخدمين. يوفر النشر بنظام الأزرق-الأخضر توافرًا شبه مستمر للخدمة، وإمكانية تراجع آمنة، مما يلعب دورًا كبيرًا في تحقيق الهدف الشامل للتكامل المستمر والتسليم المستمر (CI/CD) والمتمثل في إصدار برمجيات بشكل متكرر وموثوق.

تُعد عمليات النشر بنهج الكناري، المستمدة من التعبير الاصطلاحي "طائر الكناري في منجم الفحم"، وسيلة أخرى لتقليل المخاطر عند نشر إصدارات البرمجيات الجديدة.

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

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

تتمثل الميزة الرئيسية للنشر بنهج الكناري مقارنةً بنظام النشر أزرق/أخضر في تكلفة البنية التحتية؛ حيث يعتمد النشر بنهج الكناري على بيئة واحدة فقط، بينما يتطلب النشر بنظام أزرق/أخضر بيئتين. غير أن عمليات النشر بنهج الكناري قد تكون أكثر تعقيداً وأعلى مخاطرة في حال استدعت الحاجة إلى التراجع، وذلك مقارنة بآلية إعادة توجيه موازنة الحمل البسيطة المتبعة في نظام الأزرق-الأخضر.

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

ومع ذلك، هناك أيضًا نهج هجين. يمكن لموازنات التحميل توجيه جزء من حركة مرور المستخدمين، ولنقل بنسبة 1%، إلى البيئة الخضراء، بينما يظل 99% منها موجهاً إلى البيئة الزرقاء. يمزج هذا التوجه بين كلتا الاستراتيجيتين بفعالية، مما يوفر رؤى دقيقة حول النشر بنهج الكناري مع القدرة على إجراء عمليات التراجع بسرعة وسهولة.

يوفر النشر بنظام أزرق-أخضر العديد من المزايا، سواء استُخدم في عملية طرح شاملة (الكل أو لا شيء) أو في عملية طرح تدريجي بنهج الكناري.

نظرا لأن موازن التحميل يحول حركة المرور فوراً إلى البيئة المطلوبة، فإن المستخدمين النهائيين لا يواجهون أي فترة تعطل. يُعد هذا ميزة كبرى للمثيلات ذات الكثافة المرورية العالية، حيث يمكن أن يؤدي وقت التعطل فيها إلى مشاكل تجارية جسيمة.

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

وجود بيئتين منفصلتين يسهّل تحليل المقاييس، والتحليلات، واختبارات A/B للإصدارات المختلفة. يمكن ربط بيانات التحليلات والمراقبة بوضوح بالبيئة الزرقاء أو الخضراء، مما يتيح المقارنة المباشرة وفحوصات السلامة. يختلف هذا عن النشر بنهج الكناري، والذي قد يصعب تمييزه نظراً لأن كلا الإصدارين يكونان نشطين في وقت واحد.

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

بينما يوفر النشر بنظام الأزرق-الأخضر العديد من المزايا، إلا أن هناك سلبيات محتملة وحالات استخدام غير مثالية يجب على فرق التطوير مراعاتها.

مع تشغيل بيئتين مجهزتين بالكامل، يمكن أن تزداد تكاليف الاستضافة والبنية التحتية. ليس من الضروري أن تكون هذه التكاليف ضعف تكلفة البيئة الواحدة تماماً. في بعض الحالات، قد تستهلك البيئة الخضراء موارد أقل، أو قد يتم إيقاف تشغيل البيئة الزرقاء بسرعة، أو قد تتم مشاركة بعض الموارد بين البيئتين. ولكن من المحتمل أن تكون هناك زيادة في التكاليف.

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

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

لمعالجة هذه المشكلة، تتضمن أدوات CI/CD مثل GitHub Actions عمليات نشر قاعدة بيانات تدير تحديثات المخطط تلقائياً. في بعض الأحيان، قد تؤدي تغييرات المخطط المعقدة للغاية إلى إبطال قيمة النشر بنظام الأزرق-الأخضر.

في التطبيقات ذات الحالة، وهي تلك التي تحتفظ ببيانات مستمرة عبر الطلبات، قد تفرض عمليات النشر بنظام الأزرق-الأخضر بعض المشكلات. يمكن أن تتضمن التطبيقات ذات الحالة عربات التسوق التي تحتفظ بمحتوياتها عبر زيارات متعددة أو سجلات المراسلة. إذا لم تكن قواعد البيانات مشتركة ومتوافقة بين البيئات، فقد تُفقد هذه البيانات.

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