ماذا يحدث بعد الضغط على زر النشر: التحقق من أن الإصدار الجديد يعمل فعليًا

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

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

الإصدار ليس خط النهاية. إنها اللحظة التي يبدأ فيها الاختبار الحقيقي.

لماذا بيئة الاختبار ليست كافية

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

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

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

ابدأ باختبار دخان

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

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

اختبارات الدخان ضحلة بطبيعتها. أنت لا تختبر كل ميزة أو حالة حافة. أنت تجيب على سؤال واحد: هل تم النشر بنجاح، أم أن التطبيق معطل عند الوصول؟

يُظهر مخطط التدفق التالي عملية التحقق بعد الإصدار الموضحة في هذه المقالة، بما في ذلك نقاط القرار للتراجع.

إليك أمر bash بسيط يمكنك تشغيله بعد النشر مباشرة لإجراء اختبار دخان:

curl -f https://prod.example.com/health && echo "Smoke test passed" || echo "Smoke test failed"
flowchart TD A[الإصدار] --> B[اختبار الدخان] B -->|نجاح| C[التحقق] B -->|فشل| D[التراجع] C -->|نجاح| E[مراقبة الصحة] C -->|فشل| D E -->|تم اكتشاف شذوذ| F{الخطورة؟} F -->|طفيف| G[إصلاح سريع] F -->|كبير| D E -->|طبيعي| H[مواصلة المراقبة] G --> E

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

انتقل إلى التحقق

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

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

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

الفرق الرئيسي عن اختبار الدخان هو العمق. اختبار الدخان يسأل "هل هو حي؟" التحقق يسأل "هل يعمل بشكل صحيح؟"

راقب إشارات الصحة

اختبارات الدخان والتحقق هي فحوصات نشطة. ترسل طلبات وتلاحظ الاستجابات. لكن هناك طبقة أخرى من الفحص تحدث بشكل سلبي: مراقبة إشارات الصحة.

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

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

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

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

كم من الوقت يجب أن تفحص؟

مدة الفحص بعد الإصدار تعتمد على التغيير.

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

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

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

عندما تسوء الأمور

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

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

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

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

قائمة تحقق عملية بعد الإصدار

إليك قائمة تحقق قصيرة يمكنك تكييفها لفريقك. اضبط العناصر بناءً على تطبيقك وتحمل المخاطر.

  • اختبار الدخان: تحميل الصفحة الرئيسية، استجابة API الحرجة، اتصال قاعدة البيانات
  • التحقق الآلي: تشغيل مجموعة الاختبارات الفرعية التي تغطي الميزات التي تم تغييرها
  • التحقق اليدوي: فحص السجلات، تأكيد إمكانية الوصول إلى الميزة الجديدة
  • إشارات الصحة: مراجعة معدل الأخطاء، وقت الاستجابة، استخدام الموارد
  • تكوين التنبيهات: التحقق من أن تنبيهات المراقبة نشطة والحدود محددة
  • معايير التراجع: تأكيد أن الفريق يعرف ما يؤدي إلى التراجع ومن يقرر

الخلاصة الحقيقية

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

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