ثمة اليوم عدد كبير من استراتيجيات النشر للاختيار من بينها، وسيزداد هذا العدد مع مرور الوقت. ومع ذلك، تبقى استراتيجيتا Canary وBlue-green من أكثر استراتيجيات النشر شيوعاً واستخداماً لدى كثير من كبرى الشركات اليوم.
عند المقارنة بين نشر Blue-Green ونشر Canary، لا يتعلق الأمر فقط بالسرعة أو البساطة؛ فمن أهم العوامل التي ينبغي مراعاتها عند اختيار إحدى هاتين الاستراتيجيتين هو وقت التوقف أثناء النشر.
لتقليل وقت التوقف أثناء النشر وضمان انتقال سلس عند نشر تحديثاتك أو تعديلاتك، يصبح اختيار الخيار الأنسب بين نشر Canary ونشر Blue-Green أمراً بالغ الأهمية.
إذن، لنستعرض ما تقدمه كل استراتيجية، بما في ذلك مقارنة مباشرة بين نشر Blue-Green ونشر Canary، إضافةً إلى تجربتنا الخاصة مع كلتا الاستراتيجيتين.
ما هو نشر Blue-Green وما الذي يقدمه؟
في استراتيجية نشر Blue-Green، يمكن نشر الإصدار الجديد من التطبيق فور اختباره والتحقق منه. يتحقق ذلك بفضل وجود بيئتين متطابقتين: البيئة الزرقاء والبيئة الخضراء، ومن هنا جاءت التسمية Blue-Green.
تعمل هذه الاستراتيجية لأن إحدى البيئتين تكون نشطة والأخرى خاملة. هذا يعني أنه يمكن نشر الإصدار الجديد من التطبيق في البيئة الخاملة، لنقل البيئة الخضراء. ونظراً لتطابق البيئتين تماماً من حيث الموارد والبنية التحتية والإعدادات، يمكن اكتشاف أي مشكلات في التحديث ومعالجتها قبل نشره بشكل كامل.
بعد اختبار التحديث واقتناع المطورين بأنه يعمل بشكل صحيح، يُحوَّل حركة المرور الحية إلى البيئة الخاملة. بذلك تصبح البيئة الخاملة، وهي الخضراء، هي البيئة النشطة، فيما تصبح البيئة النشطة سابقاً، وهي الزرقاء، خاملة.
تصبح البيئة الزرقاء الخاملة الآن بيئة احتياطية يمكن استخدامها لاختبار التحديثات الأحدث، في حين تعمل البيئة الخضراء النشطة بالتحديث المنشور حديثاً. وبهذه الطريقة، لا يكاد يكون هناك أي وقت توقف، إذ تنتقل حركة المرور فوراً إلى البيئة الخاملة.
علاوة على ذلك، إذا ظهرت أي مشكلات في التحديث، تتيح ميزة التراجع العودة إلى الإصدار السابق من تطبيقك. غير أنه إن بدأ المطورون العمل على تحديث جديد في البيئة الخاملة وظهرت مشكلات بعد ذلك، فلن يكون التراجع إلى هذه البيئة ممكناً، إذ لم يعد الإصدار القديم متاحاً فيها بعد الآن.
تستخدم كثير من الشركات والمؤسسات هذه الاستراتيجية، ومن أبرز الأمثلة عليها Spotify. ونظراً لضرورة إتاحة خدمات Spotify على مدار الساعة طوال أيام الأسبوع، تحتفظ دائماً بالبيئة الخاملة الاحتياطية جاهزة عند إصدار تحديثات جديدة.
ما هو نشر Canary وما الذي يقدمه؟
الفارق الرئيسي بين نشر Canary ونشر Blue-Green هو أنه بدلاً من امتلاك بيئتين يُنشر فيهما التحديث دفعةً واحدة لجميع المستخدمين، تُطلق استراتيجية نشر Canary التحديثات أولاً على شريحة صغيرة من المستخدمين.
إذا اكتُشفت أي مشكلات في التحديث، فلن يواجهها سوى عدد محدود من المستخدمين الذين يقدمون تغذية راجعة. وبعد معالجة هذه المشكلات، يُطلق التحديث لشريحة أوسع من المستخدمين، الذين يبلغون المطورين بأي مشكلات يصادفونها.
تتكرر هذه الدورة مع شرائح متزايدة تدريجياً من المستخدمين، وتُعالج جميع المشكلات حتى يصل التحديث إلى ١٠٠٪ من المستخدمين. على سبيل المثال، قد يُطلق التحديث في البداية لـ ٢٪ فقط، ثم لـ ٢٥٪، ثم لـ ٧٥٪، وأخيراً لجميع المستخدمين.
يتيح هذا الإطلاق التدريجي في نشر Canary مقارنةً بنشر Blue-Green تحكماً أكبر ومرونةً في طرح الميزات والتحديثات، إذ يختبرها المطورون في بيئة محكومة لا تتأثر فيها إلا شريحة صغيرة من المستخدمين بأي مشكلات محتملة.
أخيرًا، يوفر نهج Canary أيضًا ميزة مماثلة للرجوع إلى الإصدار السابق، غير أن هذا الرجوع يتم بصورة تدريجية ومرحلية، تمامًا كما يجري النشر نفسه، وذلك حتى الوصول إلى إصدار مستقر.
من أبرز الأمثلة على هذه الاستراتيجية، استخدام Netflix لنهج Canary جنبًا إلى جنب مع أداة تُعرف بـ Chaos Monkey، التي تعمد إلى حقن أعطال في النظام. فإذا أثّر عطل ما على بيئة Canary، تمكّن فريق Netflix من تحليل استجابة النظام والتعديل بناءً على ذلك. بهذه الطريقة، يتحقق الفريق من أن التحديث يظل مستقرًا وصامدًا حتى في ظل الظروف الصعبة.
نشر Blue-Green مقابل Canary
تتمتع كلتا الاستراتيجيتين بمزايا مميزة لكل منهما، إلا أن لكل منهما حدودها وقيودها. لهذا السبب، من الضروري الموازنة بين إيجابيات وسلبيات Blue-Green وCanary قبل اتخاذ القرار.
إن كنت لا تزال غير متأكد من أيهما تختار بعد قراءة هذا القسم، فقد أضفت في نهاية المقال تجربتنا مع هاتين الاستراتيجيتين والدروس التي خرجنا بها.
تقليل وقت التوقف
من أبرز المحاور التي تتناولها هذه المقالة: تقليل وقت التوقف أثناء النشر عند المقارنة بين Blue-Green وCanary. تتميز Blue-Green بسرعتها، إذ تتيح نشر تحديث التطبيق أو الميزة الجديدة فورًا عبر بيئتيها المنفصلتين.
في المقابل، يُتيح نهج Canary التدريجي تقليص أوقات التوقف إلى أدنى حد، إذ لا تتأثر بالمشكلات سوى شريحة صغيرة من المستخدمين، كما أن التغذية الراجعة في كل مرحلة تُعجّل باكتشاف الأخطاء وحلها دون أي توقف.
فضلًا عن ذلك، تدعم الاستراتيجيتان ميزة الرجوع إلى الإصدار السابق، غير أن هذا الرجوع في Blue-Green يتم فوريًا، مما يمنح المطورين خيارًا احتياطيًا موثوقًا في حال وقوع مشكلات جسيمة. ومع ذلك، وكما أشرت سابقًا، لن يكون الإصدار الاحتياطي متاحًا إذا كانت البيئة غير النشطة تُستخدم في العمل على إصدار أحدث.
لا يمكن استخدام ميزة الرجوع في Canary إلا بصورة تدريجية، تمامًا كما يجري النشر. في المقابل، تظل هذه الميزة متاحة دائمًا، إذ لا يرتبط الإصدار المستقر القديم بالبيئة التي تُختبر فيها التحديثات الجديدة.
من حيث تقليل وقت التوقف، يتفوق Canary على Blue-Green في ضبط المخاطر والتحكم الدقيق في عملية النشر. أما إذا كان الهدف الرئيسي هو تقليص وقت التوقف تحديدًا، فإن Blue-Green يكون الخيار الأفضل من الاثنين نظرًا لأن التبديل يتم فوريًا.
بيد أن المقارنة بين Blue-Green وCanary لا تقتصر على معيار وقت التوقف وحده، بل ثمة عوامل أخرى لا يمكن إغفالها.
نوع التطبيق
يمكن تصنيف التطبيقات عمومًا إلى تطبيقات كثيفة المعاملات وتطبيقات قائمة على المحتوى. بالنسبة لتطبيقات المعاملات، يُعدّ Blue-Green الخيار الأنسب بفارق واضح، إذ تُولي هذه التطبيقات أولوية قصوى لتوافر الخدمة وتقليص وقت التوقف، وهو ما تتيحه ميزتا التبديل الفوري والرجوع الفوري في Blue-Green.
أما التطبيقات القائمة على المحتوى، فلا تعتمد على معاملات آنية. وبما أن هذه التطبيقات تُستخدم عادةً في منصات التواصل الاجتماعي وخدمات تفاعل المستخدمين، يُعدّ Canary الاستراتيجية الأمثل لها، إذ يُتيح طرح التحديثات تدريجيًا واستقبال التغذية الراجعة في كل مرحلة.
تكاليف البنية التحتية
من المحاور الرئيسية الأخرى عند المقارنة بين Blue-Green وCanary: التكلفة. من الطبيعي أن تكون تكاليف Blue-Green أعلى، نظرًا للحاجة إلى صيانة بيئتين مستقلتين في آنٍ واحد.
لهذا السبب، تُعدّ بيئة الإنتاج الواحدة في Canary خيارًا أوفر من حيث التكلفة، مما يجعلها مناسبة للفرق الصغيرة أو التطبيقات التي لا تستهلك موارد ضخمة.
قابلية التوسع والصيانة على المدى البعيد
أخيرًا، رغم أن Blue-Green يدعم التوسع، فإن الحفاظ على بيئتين كاملتين للتطبيقات واسعة النطاق قد يستنزف الموارد ويُضيف تعقيدات كبيرة. ومع مرور الوقت، يُفضي إدارة البيئتين المتطابقتين وصيانتهما إلى أعباء تشغيلية متزايدة، ولا سيما للتطبيقات ذات البنية التحتية المعقدة.
هذا يجعل المقارنة بين Canary وBlue-Green من حيث قابلية التوسع والصيانة أمرًا واضحًا نسبيًا. مع Canary، يكون التوسع في الغالب أبسط وأقل تكلفة، إذ لا يستلزم الأمر بيئات مكررة.
بدلًا من ذلك، يعتمد على التوسع داخل البيئة الأساسية بتوسيع قاعدة المستخدمين المعرّضين للتغييرات الجديدة تدريجيًا. هذا النهج أسهل في الإدارة على المدى البعيد، إذ يُخفف من تعقيد البنية التحتية ويُبسّط متطلبات الصيانة.
تجربة Cloudzy مع نشر Blue-Green مقابل نشر Canary
عند تقديمنا خدمات DevOps للعملاء، ندرك جيدًا أن رضا العميل وتوافر الخدمة وتقليص وقت التوقف تُمثّل ركائز أساسية لنجاح أعمالهم. في حالة بعينها، تواصل معنا أحد العملاء طالبًا المساعدة في تحديث بنية تحتية رئيسية. كان على الفريق الاختيار بين Blue-Green وCanary لتنفيذ هذا التحديث.
بعد تداول مُستفيض، قررنا في البداية تجربة Blue-Green نظرًا لما يوفره من توقف شبه معدوم. أعددنا بيئة green مطابقة واستعددنا لطرح التحديث. كان الضغط محسوسًا، إذ يكفي ضغطة زر واحدة لتحويل كل حركة المرور إلى البيئة الجديدة، وكما يعرف كل مطور، مهما أجريت من اختبارات، يظل هناك قدر من المجهول في النتيجة النهائية.
لحسن الحظ، سارت الأمور على ما يرام. كان الانتقال سلسًا تمامًا، ولم نواجه سوى مشكلات طفيفة. مع مرور الوقت، وبازدياد خدمات العميل وتنامي قاعدة مستخدميه، احتجنا إلى طرح ميزات جديدة، فعاد النقاش حول Blue-Green وCanary مجددًا.
هذه المرة، لم يكن ثمة جدل يُذكر. كانت الميزات أصغر نسبيًا وبعيدة كل البعد عن حجم ذلك التحديث البنيوي. لذا، اخترنا Canary بطبيعة الحال، إذ أتاح لنا طرح الميزات لشرائح صغيرة من مستخدمي العميل ومعالجة أي مشكلات بناءً على تغذيتهم الراجعة.
كان ذلك بلا شك القرار الصائب، إذ رغم غياب أي مشكلات كبرى، بدأت بعض المشكلات الصغيرة بالظهور، وقد رصدها الـ 5% من قاعدة مستخدمي العميل الذين طُرحت لهم الميزة.
في Cloudzy، نؤمن بقيمة الحلول المصممة وفق احتياجات كل عميل. سواء احتاج عملك إلى موثوقية Blue-Green أو مرونة Canary، يمتلك فريق DevOps لدينا الخبرة والمعرفة اللازمتين لتطبيق الاستراتيجية الأنسب لبنيتك التحتية. تواصل معنا هنا اليوم لمعرفة كيف يمكننا تحسين عملية النشر لديك وضمان استمرارية عملياتك دون انقطاع.
بالحديث عن VPS، نقدم بعض أدنى الأسعار في مجال VPS، مع مجموعة من المميزات تشمل: أكثر من ١٢ موقعًا حول العالم، واتصالات إنترنت مخصصة تصل سرعتها إلى 10 Gbps، وتخزين NVMe SSD للمؤسسات، ومعالجات AMD EPYC بسرعة توربو تبلغ 3.23 GHz، ونسبة تشغيل 99.95%. اطّلع على أسعار VPS لمزيد من التفاصيل.
الخاتمة
في نهاية المطاف، لا يمكن القول بشكل قاطع إن إحدى الاستراتيجيتين أفضل من الأخرى بصورة جوهرية عند المقارنة بين نشر Canary ونشر Blue-Green. الأمر يتوقف على حالة الاستخدام وأيهما يناسب متطلباتك تحديداً.
الأسئلة الشائعة
ما الفرق الرئيسي بين نشر Blue-Green ونشر Canary؟
الفرق الجوهري بين استراتيجيتي النشر Blue-Green وCanary يكمن في طريقة إصدار التحديثات. يعتمد نشر Blue-Green على بيئتين متطابقتين، إذ تُطبَّق التحديثات على البيئة غير النشطة، مما يتيح التبديل الفوري مع انقطاع شبه معدوم. في المقابل، يُطلق نشر Canary التحديثات تدريجياً على شريحة صغيرة من المستخدمين أولاً، مع مراقبة الأداء قبل التوسع التدريجي ليشمل قاعدة المستخدمين بأكملها.
أيهما أفضل لتقليل وقت التوقف: نشر Blue-Green أم نشر Canary؟
يتفوق نشر Blue-Green عموماً في تقليل وقت التوقف، نظراً لأنه يتيح التبديل الفوري بين البيئتين، مما يُقلص أي اضطرابات محتملة إلى أدنى حد. أما نشر Canary فيسعى هو الآخر إلى تقليص وقت التوقف، لكنه يفعل ذلك عبر طرح تدريجي قد يُفضي إلى مشكلات طفيفة ومحدودة تؤثر على شريحة صغيرة فحسب من المستخدمين.
ما اعتبارات التكلفة عند المقارنة بين نشر Blue-Green ونشر Canary؟
يكون نشر Blue-Green أعلى تكلفةً في الغالب، إذ يستلزم الإبقاء على بيئتين كاملتين في آنٍ واحد. في المقابل، يُعدّ نشر Canary أكثر كفاءةً من حيث التكلفة، لأنه لا يتطلب بنية تحتية مضاعفة؛ فالتحديثات تُطرح داخل البيئة الأساسية ذاتها، مما يجعله خياراً أنسب للفرق الصغيرة أو التطبيقات التي لا تستهلك موارد كثيرة.
