افصل النشر عن التحويل
يمكن نشر الإصدار الجديد وتشغيل smoke tests عليه قبل استقبال مستخدمين، ثم تحويل load balancer أو route عندما يصبح جاهزًا.
قاعدة البيانات هي التحدي المعتاد
إذا غيّر الإصدار schema بطريقة لا يفهمها الإصدار القديم، لن يكون الرجوع بسيطًا. استخدم migrations متوافقة مرحليًا عند الحاجة.
ما الفرق بين Blue و Green أثناء النشر؟
احتفظ ببيئتين تتشابهان قدر الإمكان من حيث الإعدادات والموارد المطلوبة: بيئة تقدم الطلبات حاليًا وأخرى يستقبل عليها الإصدار الجديد عمليات الفحص. أسماء الألوان رمزية وليست نوعًا من البنية. الهدف هو أن يحدث تثبيت الحزمة والتهيئة واختبار الاتصال قبل تحويل حركة المستخدمين. هذا يقلل احتمال ظهور خطأ تثبيت أثناء النشر، لكنه لا يلغي خطر خطأ وظيفي لا تكشفه الاختبارات المسبقة.
اختبارات لا بد منها قبل تحويل الترافيك
تحقق من إقلاع الخدمة واتصالها بالاعتماديات الأساسية، ووجود متغيرات البيئة والأسرار، وقدرة المسارات الصحية على الرد. شغّل Smoke Tests لمسارات حقيقية ولكن ببيانات اختبار آمنة، واختبر تسجيل الدخول وقراءة البيانات وعمليات الكتابة الأساسية إن كان ذلك مناسبًا. راقب استهلاك الموارد وزمن الاستجابة والأخطاء، ولا تعتمد على HTTP 200 من صفحة ثابتة كدليل كافٍ على سلامة التطبيق.
تحويل تدريجي بدل قفزة غير مراقبة
يمكن أن يوجه موازن التحميل جزءًا من الطلبات إلى النسخة الجديدة قبل التحويل الكامل إذا كانت البنية تدعم ذلك، مع مراعاة الجلسات الطويلة والاتصالات المستمرة. ثبت مؤشرات واضحة للنجاح، مثل معدل الأخطاء ووقت الاستجابة ونجاح المعاملات، وقارنها بخط أساس قبل النشر. لا تترك التبديل يعتمد على قرار شخصي غير موثق؛ ضع حدودًا للإيقاف وخطة رجوع يتم اختبارها مسبقًا.
عقبة قاعدة البيانات وترحيلات Schema
عندما يشترك الإصداران في قاعدة بيانات واحدة، قد يضيف الجديد عمودًا أو يغير طريقة قراءة البيانات. إذا أزلت عمودًا فورًا فلن يستطيع القديم العمل بعد الرجوع. استخدم أسلوب Expand ثم Migrate ثم Contract: أضف البنية الجديدة أولًا، واجعل الإصدارين قادرين على التعامل مع المرحلة الانتقالية، وانقل البيانات إذا لزم الأمر، ثم أزل القديم بعد التحقق. نجاح تبديل السيرفر لا يعني نجاح العودة إلى إصدار سابق بعد تغييرات البيانات.
التحقق بعد التحويل
راقب الحركة الداخلة والخارجة ومعدلات الأخطاء وأداء قاعدة البيانات واستهلاك الذاكرة والتبعيات الخارجية. تأكد من أن ال ـLoad Balancer لا يرسل طلبات جديدة إلى النسخة القديمة قبل فصلها، مع السماح للجلسات الجارية بإنهاء العمل عند الحاجة. افحص أيضًا مسارات الخلفية مثل العمال والمهام المجدولة حتى لا تعمل النسختان على معالجة نفس الحدث بطريقة تسبب ازدواجًا.
متى تحتاج Rollback ومتى تحتاج Roll Forward؟
العودة للبيئة السابقة مناسبة عندما تكون متوافقة مع البيانات والتغييرات التي حدثت بعد التبديل. إذا كان الإصدار الجديد قد عدل صيغة بيانات يصعب على القديم قراءتها، فالعودة السريعة للترافيك قد تخلق أعطالًا أكبر. حينئذ قد يكون إصلاح عاجل إلى الأمام هو الأسلم، بناءً على تقييم الحادث وخطة واضحة. لا تعتبر نقل حركة المرور زرًا سحريًا يلغي أثر أي عملية كتابة تمت بالفعل.
قائمة استلام عملية للإصدار
وثق رقم النسخة وال ـCommit وخط الأساس ومجموعة اختبارات القبول ونتيجة ترحيل البيانات. سجّل وقت التحويل والمسؤول عنه ووقت انتهاء مراقبة ما بعد النشر. احتفظ بالبيئة السابقة مدة معقولة وفق سياسة التشغيل وليس إلى أجل مفتوح دون تكلفة محسوبة. نجاح النشر يقاس باستقرار الخدمة وسلامة البيانات وإمكانية التعافي، وليس بمجرد اختفاء رسالة خطأ من واجهة الإدارة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…