كيف تتحقق من أن الإصدار الجديد يعمل بالفعل

لقد انتهيت للتو من النشر. خط أنابيب CI/CD أخضر. الإصدار الجديد يعمل. أحد أعضاء الفريق يفتح المتصفح، يحمل الصفحة الرئيسية، ويقول "تبدو جيدة." الجميع يطلقون زفرة ارتياح وينتقلون إلى المهمة التالية.

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

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

مشكلة الفحوصات اليدوية

الفحوصات اليدوية بعد النشر تعاني من ثلاثة عيوب أساسية.

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

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

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

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

ابدأ باختبارات الدخان (Smoke Tests)

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

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

قد يتضمن اختبار الدخان النموذجي ما يلي:

إليك مثال ملموس لسكريبت اختبار دخان يمكنك تشغيله بعد كل نشر:

#!/bin/bash
# smoke-test.sh - تشغيل فحوصات دخان أساسية بعد النشر

BASE_URL="http://localhost:8080"
FAILED=0

check_endpoint() {
  local url="$1"
  local description="$2"
  local status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  if [ "$status" -eq 200 ]; then
    echo "PASS: $description"
  else
    echo "FAIL: $description (HTTP $status)"
    FAILED=1
  fi
}

check_endpoint "$BASE_URL/" "الصفحة الرئيسية تعيد 200"
check_endpoint "$BASE_URL/login" "صفحة تسجيل الدخول تُعرض"
check_endpoint "$BASE_URL/api/health" "نقطة نهاية الصحة تستجيب"
check_endpoint "$BASE_URL/static/css/main.css" "ملف CSS يُحمل"

if [ "$FAILED" -eq 1 ]; then
  echo "فشلت اختبارات الدخان. يُوصى بالتراجع."
  exit 1
else
  echo "جميع اختبارات الدخان ناجحة."
fi

• تحميل الصفحة الرئيسية والتأكد من أنها تعيد HTTP 200
• التحقق من أن صفحة تسجيل الدخول تُعرض بدون أخطاء
• التأكد من أن نقطة نهاية API حرجة تستجيب في وقت معقول
• تأكيد أن الأصول الثابتة مثل ملفات CSS وJavaScript تُحمل بشكل صحيح

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

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

تعمق أكثر باستخدام المعاملات الاصطناعية (Synthetic Transactions)

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

المعاملة الاصطناعية لا تتحقق فقط مما إذا كانت الصفحة تُحمل. إنها تسير خلال تدفق مستخدم فعلي. على سبيل المثال:

1. افتح الصفحة الرئيسية
2. انقر على زر تسجيل الدخول
3. أدخل اسم مستخدم وكلمة مرور اختبارية
4. أرسل نموذج تسجيل الدخول
5. انتقل إلى ميزة معينة
6. املأ نموذجًا ببيانات اختبارية
7. أرسل النموذج
8. تحقق من ظهور النتيجة المتوقعة في الصفحة التالية

تختلف المعاملات الاصطناعية عن اختبارات الدخان بطريقتين مهمتين.

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

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

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

قم بتشغيل كليهما فورًا بعد النشر

تعمل اختبارات الدخان والمعاملات الاصطناعية بشكل أفضل كخط أنابيب تحقق من خطوتين.

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

الرسم البياني أدناه يوضح تدفق القرار الآلي:

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

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

قائمة تحقق عملية للتحقق

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

• اختبار دخان: الصفحة الرئيسية تعيد 200
• اختبار دخان: صفحة تسجيل الدخول تُعرض بدون أخطاء
• اختبار دخان: نقطة نهاية API حرجة تستجيب في أقل من ثانيتين
• اختبار دخان: الأصول الثابتة تُحمل بشكل صحيح
• معاملة اصطناعية: يمكن للمستخدم تسجيل الدخول ببيانات اختبارية
• معاملة اصطناعية: يمكن للمستخدم إكمال سير عمل أساسي (مثل إنشاء طلب، إرسال نموذج، عرض تقرير)
• معاملة اصطناعية: البيانات التي تم إنشاؤها أثناء الاختبار مرئية في الموقع المتوقع

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

كيف يبدو هذا عمليًا

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

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

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

هذا هو الفرق بين التحقق المنظم والأمل في الأفضل.

ليس كل شيء يمكن التحقق منه بنفس الطريقة

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

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

الخلاصة العملية

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

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