بعد النشر: ما يجب التحقق منه قبل اعتبار المهمة منتهية

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

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

لماذا نجاح خط الأنابيب غير كافٍ

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

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

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

الفرق بين النشر والتحقق

النشر هو عملية وضع إصدار جديد في بيئة ما. التحقق هو عملية التأكد من أن الإصدار الجديد يعمل كما هو متوقع في تلك البيئة.

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

يوضح المخطط الانسيابي التالي كيف أن النشر والتحقق مساران منفصلان يجب أن ينجح كلاهما قبل اعتبار النشر مكتملاً:

flowchart TD A[Pipeline Green] --> B[Deployment Script Runs] B --> C[Artifacts Uploaded] C --> D[Deployment Track Complete] D --> E{Verification Track} E --> F[Smoke Test] F --> G{Pass?} G -- No --> H[Rollback] G -- Yes --> I[Check Error Rate] I --> J{Within Threshold?} J -- No --> H J -- Yes --> K[Check Latency] K --> L{Within Bounds?} L -- No --> H L -- Yes --> M[Check Throughput] M --> N{Expected Volume?} N -- No --> H N -- Yes --> O[Deployment Complete]

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

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

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

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

قد يتضمن اختبار الدخان العملي ما يلي:

إليك سكريبت bash بسيط يقوم بتشغيل اختبار دخان ضد نقطة نهاية منشورة ويخرج برمز خطأ غير صفري عند الفشل:

#!/bin/bash
# smoke-test.sh - Quick check that the deployed version is alive

URL="https://your-app.example.com/health"
EXPECTED_STATUS=200

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_STATUS" -ne "$EXPECTED_STATUS" ]; then
    echo "Smoke test failed: expected status $EXPECTED_STATUS, got $HTTP_STATUS"
    exit 1
fi

echo "Smoke test passed: $URL returned $HTTP_STATUS"
exit 0
  • الوصول إلى الصفحة الرئيسية والتحقق من استجابة 200
  • استدعاء نقطة نهاية API بسيطة والتحقق من هيكل الاستجابة
  • تأكيد أن اتصال قاعدة البيانات نشط
  • التحقق من تحميل الأصول الثابتة بشكل صحيح

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

تحقق من الإشارات الأساسية

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

الإشارات التي تحتاجها تعتمد على ما نشرته، لكن بعضها عالمي:

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

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

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

التحقق جزء من النشر

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

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

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

أنواع مختلفة من التغييرات تحتاج فحوصات مختلفة

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

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

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

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

المبدأ هو نفسه: حدد ما يمكن أن يحدث خطأ لهذا النوع المحدد من التغيير، وتحقق من تلك الأشياء قبل اعتبار النشر مكتملاً.

قائمة تحقق عملية بعد النشر

إذا كنت تريد شيئًا ملموسًا للبدء به، إليك قائمة تحقق بسيطة تعمل مع معظم تطبيقات الويب:

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

هذه القائمة ليست شاملة، لكنها تغطي الأساسيات. يمكنك توسيعها كلما تعلمت الإشارات الأكثر أهمية لنظامك المحدد.

الخلاصة

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