ما الذي يُعتبر نشرًا صحيًا للتطبيقات وقواعد البيانات والبنية التحتية

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

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

التحقق من نشر التطبيق

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

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

flowchart TD subgraph App[Application] A1[Health check] --> A2[Smoke tests] A2 --> A3[Synthetic transactions] A3 --> A4{All pass?} A4 -->|Yes| A5[Healthy] A4 -->|No| A6[Rollback] end subgraph DB[Database] D1[Migration check] --> D2[Data integrity check] D2 --> D3[Query performance check] D3 --> D4{All pass?} D4 -->|Yes| D5[Healthy] D4 -->|No| D6[Rollback] end subgraph Infra[Infrastructure] I1[Config validation] --> I2[Connectivity test] I2 --> I3[Resource limits check] I3 --> I4{All pass?} I4 -->|Yes| I5[Healthy] I4 -->|No| I6[Rollback] end

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

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

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

فيما يلي مثال عملي لفحص صحي ونص برمجي لمعاملة اصطناعية يمكنك تشغيله بعد النشر:

# Health check: verify the app is alive
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep -q "200"; then
  echo "Health check passed"
else
  echo "Health check failed"
  exit 1
fi

# Smoke test: simulate a core user flow (login, search, submit)
#!/bin/bash
set -euo pipefail

BASE_URL="http://localhost:8080"

# Step 1: Login
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","password":"testpass"}')
TOKEN=$(echo "$LOGIN_RESPONSE" | jq -r '.token')

# Step 2: Search
SEARCH_RESPONSE=$(curl -s "$BASE_URL/search?q=test&date_from=2024-01-01" \
  -H "Authorization: Bearer $TOKEN")
if ! echo "$SEARCH_RESPONSE" | jq -e '.results | length > 0' > /dev/null; then
  echo "Search returned no results"
  exit 1
fi

# Step 3: Submit form
SUBMIT_RESPONSE=$(curl -s -X POST "$BASE_URL/submit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"test","content":"test content"}')
if ! echo "$SUBMIT_RESPONSE" | jq -e '.id' > /dev/null; then
  echo "Form submission failed"
  exit 1
fi

echo "Smoke test passed"

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

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

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

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

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

التحقق من تغييرات البنية التحتية

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

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

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

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

المبدأ المشترك

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

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

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

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

متى يكون النشر قد اكتمل فعلاً؟

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

هذا الدليل هو ما يفصل بين النشر الذي حدث والنشر الذي نجح.