متى يمكن اعتبار النشر مكتملاً حقاً؟

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

لكن هل النشر قد انتهى فعلاً؟

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

الفرق بين النشر والسلامة

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

يُوضح المخطط الانسيابي التالي عملية المرحلتين الموصوفة أعلاه:

flowchart TD A[مرحلة النشر] --> B[نقل الملفات / إعادة تشغيل الخدمات] B --> C[النشر ناجح] C --> D[مرحلة التحقق] D --> E[اختبارات التدخين] E --> F[المعاملات الاصطناعية] F --> G[إشارات المراقبة] G --> H[معدل الخطأ, زمن الاستجابة, الموارد] H --> I[تم جمع الأدلة] I --> J[النشر مكتمل] C -.->|غير منتهي| K[النشر غير مكتمل] style J fill:#a3d9a5 style K fill:#f4a3a3

فكر في ما يمكن أن يحدث بشكل خاطئ بعد نشر ناجح:

  • الكود الجديد يحتوي على خطأ في التكوين يظهر فقط تحت حركة المرور الحقيقية
  • ترحيل قاعدة البيانات نجح لكن كود التطبيق يتوقع اسم عمود مختلف
  • تم تحديث تابع (dependency) وكسر تكاملاً لم تلتقطه اختبارات الوحدة
  • الإصدار الجديد يستخدم ذاكرة أكثر ويُشغل قاتل OOM بعد بضع دقائق

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

ما يُعتبر دليلاً

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

يأتي الدليل من مصادر متعددة. اختبارات التدخين (Smoke tests) هي الطبقة الأساسية. تتحقق من أن التطبيق يبدأ، والصفحة الرئيسية تُحمل، والميزات الأساسية تستجيب. فشل اختبار التدخين يعني أن هناك شيئاً أساسياً خاطئاً.

إليك نص برمجي بسيط يؤتمت الطبقة الأولى من جمع الأدلة بعد النشر:

#!/bin/bash
# post-deploy-verify.sh - Run after deploy command

set -euo pipefail

URL="https://your-app.example.com"
DB_CONN_STRING="postgresql://user:pass@db-host:5432/app"

# 1. Health check
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: Health check returned $HTTP_CODE"
  exit 1
fi
echo "PASS: Health check returned 200"

# 2. Smoke test - main page loads
if ! curl -s "$URL" | grep -q "<title>App</title>"; then
  echo "FAIL: Main page missing expected title"
  exit 1
fi
echo "PASS: Main page loads correctly"

# 3. Database connectivity test
if ! psql "$DB_CONN_STRING" -c "SELECT 1" > /dev/null 2>&1; then
  echo "FAIL: Database connection failed"
  exit 1
fi
echo "PASS: Database connection successful"

echo "All checks passed - deployment evidence collected"

المعاملات الاصطناعية (Synthetic transactions) تتعمق أكثر. تحاكي تدفقات المستخدم الحقيقية: تسجيل الدخول، البحث عن البيانات، تقديم نموذج، إتمام طلب. إذا نجحت معاملة اصطناعية، فأنت تعلم أن رحلة مستخدم كاملة تعمل من البداية إلى النهاية.

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

فخ التحقق العشوائي

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

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

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

مجموعة معقولة من المعايير قد تبدو هكذا:

  • اختبار التدخين للصفحة الرئيسية وتدفق تسجيل الدخول ينجح
  • المعاملات الاصطناعية لرحلات المستخدم الثلاث الأكثر أهمية تنجح
  • معدل الخطأ يبقى أقل من 0.1 بالمائة
  • زمن الاستجابة P95 لا يزيد أكثر من 5 بالمائة عن خط الأساس قبل النشر
  • استخدام تجمع اتصالات قاعدة البيانات يبقى أقل من 70 بالمائة

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

من يقرر أن النشر مكتمل

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

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

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

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

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

إليك قائمة تحقق بسيطة يمكنك تكييفها لفريقك:

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

إذا فشل أي بند، فإن النشر لم يكتمل. حقق قبل إعلان النجاح.

ما الذي يتغير عندما تفعل هذا بشكل صحيح

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

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

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