لماذا ستفشل الفحوصات اليدوية بعد النشر (وماذا تفعل بدلاً من ذلك)

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

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

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

التكلفة الحقيقية للفحوصات اليدوية بعد النشر

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

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

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

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

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

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

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

يُظهر مخطط التدفق التالي المقارنة بين النهج اليدوي والنهج الآلي الموضح هنا:

flowchart TD subgraph Manual[الفحوصات اليدوية بعد النشر] A[نشر إصدار جديد] --> B[فتح المتصفح] B --> C[النقر على الصفحات] C --> D[التحقق من قاعدة البيانات] D --> E[افتراض أن كل شيء على ما يرام] E --> F[إغلاق التبويب والانتقال] F --> G[اكتشاف المشكلات لاحقًا] end subgraph Automated[الفحوصات الآلية بعد النشر] H[نشر إصدار جديد] --> I[خط الأنابيب يشغل اختبارات الدخان] I --> J[خط الأنابيب يشغل المعاملات الاصطناعية] J --> K{هل نجحت كل الفحوصات؟} K -->|نعم| L[تأكيد صحة الإصدار] K -->|لا| M[تنبيه الفريق فورًا] M --> N[التحقيق في الفشل المحدد] end Manual -.->|غير موثوق| O[الفريق يدفع الثمن] Automated -.->|موثوق| P[الفريق لديه دليل]

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

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

إليك مثال بسيط على ما قد يبدو عليه نص الفحص الآلي:

#!/bin/bash
# post-deploy-check.sh
# يتم تشغيله بعد النشر للتحقق من صحة التطبيق.

BASE_URL="https://your-app.example.com"
PASS=0
FAIL=1

# اختبار الدخان: التحقق من نقطة النهاية الرئيسية
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "فشل: نقطة النهاية الرئيسية أعادت $HTTP_CODE"
  exit $FAIL
fi
echo "نجاح: نقطة النهاية الرئيسية قابلة للوصول"

# معاملة اصطناعية: محاكاة تدفق تسجيل دخول المستخدم
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"test_user","password":"test_pass"}')

if echo "$LOGIN_RESPONSE" | grep -q '"token"'; then
  echo "نجاح: تدفق تسجيل الدخول يعمل"
else
  echo "فشل: تدفق تسجيل الدخول فشل"
  exit $FAIL
fi

echo "نجحت جميع الفحوصات. النشر سليم."
exit $PASS

نوعان من الفحوصات الآلية التي يمكنك البدء بها

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

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

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

  • هل يمكن للتطبيق قبول اتصالات الشبكة؟
  • هل تعيد نقطة النهاية الرئيسية رمز الحالة 200؟
  • هل يمكن للإصدار الجديد الوصول إلى قاعدة البيانات؟
  • هل نقاط نهاية API الهامة تستجيب؟

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

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

المعاملات الاصطناعية (Synthetic Transactions)

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

لتطبيق التجارة الإلكترونية، قد تقوم المعاملة الاصطناعية بما يلي:

  1. فتح صفحة قائمة المنتجات
  2. النقر على منتج معين
  3. إضافته إلى سلة التسوق
  4. الانتقال إلى الدفع
  5. ملء تفاصيل الشحن
  6. تأكيد الطلب

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

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

ما يجب أتمتته أولاً

لا تحاول أتمتة كل شيء دفعة واحدة. ابدأ بالوظائف التي قد تسبب أكبر قدر من الألم إذا تعطلت.

اسأل فريقك: "إذا نشرنا وتوقفت هذه الميزة عن العمل، ما مدى سرعة ملاحظة المستخدمين؟ ما مقدار الضرر الذي قد تسببه؟"

الإجابات تخبرك بما يجب أتمتته أولاً. بالنسبة لمعظم التطبيقات، هذا يعني:

  • المصادقة وتسجيل الدخول
  • وظيفة البحث
  • تدفقات المعاملات الأساسية (الدفع، السداد، الحجز)
  • نماذج إرسال البيانات
  • نقاط نهاية API التي تعتمد عليها الخدمات الأخرى

ابدأ بواحد أو اثنين من السيناريوهات. قم بتشغيلها باستمرار بعد كل نشر. أضف المزيد بمرور الوقت مع رؤية ما يتعطل وما هو مهم.

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

جعل النتائج مرئية

الفحوصات الآلية مفيدة فقط إذا كانت نتائجها مرئية وقابلة للتنفيذ.

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

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

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

الخطوة التالية: من التحقق إلى القرار

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

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

قائمة مهام عملية للبدء

قبل بناء نظام أتمتة كامل، ابدأ صغيرًا:

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

الخلاصة الملموسة

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

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

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