ماذا تختبر في CI وماذا تؤجل إلى CD؟

ياسر نجيب
•
•
آخر مراجعة:
•
9 دقائق قراءة

القرار المباشر: ضع الاختبارات الحتمية والمعزولة والسريعة في CI. ضع اختبارات البيئة والنشر والترحيل والحركة والمراقبة والاستعادة في CD. شغل مجموعة حرجة صغيرة بعد نشر الإنتاج.

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

القرار في دقيقة

  • تنتمي Lint والأنواع وUnit وسياسة التبعيات ومعظم Component قبل الدمج.
  • تنتمي Integration والعقود إلى CI عندما يمكن إنشاء الاعتماديات أو محاكاتها بصورة قابلة للتكرار.
  • تحتاج تجربة الترحيل Schema شبيهاً بالإنتاج وخصائص بيانات مجهولة ثم بوابة حقيقية قبل الحركة.
  • يجب أن تغطي اختبارات المتصفح والإتاحة الرحلات الحرجة في CI وأن تعيد Smoke على رابط النشر.
  • تحتاج اختبارات الأداء والتحميل خط أساس ثابتاً، ويجدول الاختبار الكبير بينما تقيم صحة Canary أثناء CD.

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

الأداة القابلة لإعادة الاستخدام

البندالقراردليل القبول
CI سريعLint وتنسيق وأنواع وUnitكل تغيير
CI متكاملAPI وقاعدة وعقد وأماناعتماديات قابلة للتكرار
قبل النشرArtifact وConfig وتجربة ترحيلشبيه بالبيئة
بعد النشرصحة وSmoke ورحلة اصطناعيةرابط منشور فعلي
تدريجيمقاييس Canary وميزانية الخطأحركة حقيقية
مجدولتحميل ومرونة واستعادةنافذة محكومة

ضع هذه المصفوفة داخل قرار المعمارية أو تذكرة التنفيذ. كل صف بلا مالك أو دليل قبول هو خطر مؤجل.

كيف تستخدم الأداة فعلياً

1. CI سريع

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

2. CI متكامل

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

3. قبل النشر

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

4. بعد النشر

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

5. تدريجي

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

6. مجدول

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

تسلسل التنفيذ

  1. تنتمي Lint والأنواع وUnit وسياسة التبعيات ومعظم Component قبل الدمج. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 1 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  2. تنتمي Integration والعقود إلى CI عندما يمكن إنشاء الاعتماديات أو محاكاتها بصورة قابلة للتكرار. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 2 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  3. تحتاج تجربة الترحيل Schema شبيهاً بالإنتاج وخصائص بيانات مجهولة ثم بوابة حقيقية قبل الحركة. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 3 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  4. يجب أن تغطي اختبارات المتصفح والإتاحة الرحلات الحرجة في CI وأن تعيد Smoke على رابط النشر. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 4 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  5. تحتاج اختبارات الأداء والتحميل خط أساس ثابتاً، ويجدول الاختبار الكبير بينما تقيم صحة Canary أثناء CD. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 5 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.

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

عقد التسليم بين DevOps والمطورين

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

يعيد مسؤول DevOps عنوان البيئة وحدود الصلاحية ومسار السجلات ولوحة القياس ومدة الاحتفاظ وخطة النشر والرجوع. قبل الموافقة يتفق الطرفان على مسؤول مراقبة الإصدار ومدة نافذة القرار وحد الإحصائي الذي يوقف Canary أو يعيد النسخة. بعد النشر لا تكفي رسالة «تم». أرفق Digest المنشور ووقت النشر ونتيجة Smoke والرابط الفعلي وحالة الترحيل وأي انحراف مقبول مع تذكرة متابعة. هذا العقد يمنع أن يصبح فشل الإعداد مشكلة مجهولة بين فريقين.

أنماط الفشل التي يجب تصميم الاختبار حولها

حزمة End-to-End واحدة تعطل كل Commit بأخطاء لا تخص التغيير.

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

CI أخضر لا يختبر النسخة المبنية أو إعداد النشر.

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

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

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

اختبار تحميل على الإنتاج بلا ضبط حركة أو مسؤول أو حدود إيقاف.

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

بوابات الاختبار والنشر

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

قبل الإنتاج شغّل الاختبارات الحتمية في CI، واختبارات البيئة والترحيل وSmoke في CD، ثم تحقق من الرحلة الحرجة على الرابط الفعلي. عرّف حد إيقاف تلقائياً لمعدل الخطأ أو p95 أو فشل الاعتماد، واحتفظ بالنسخة السابقة وإجراء استعادة البيانات. النجاح هو دليل يمكن قراءته، لا لون أخضر وحده.

التكلفة دون رقم تسويقي

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

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

ملاحظة من التشغيل

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

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

الخطوات العملية التالية

  1. انسخ الأداة أعلاه واملأها بأرقام النظام ومسؤوليه لا بتوقعات المبيعات.
  2. اختر أخطر فرضيتين ونفذ لهما اختبار فشل واستعادة في بيئة غير إنتاجية.
  3. سجل القرار والبدائل والتكلفة ودليل القبول وتاريخ المراجعة.
  4. اربط هذه المقالة بالمقالات الأخرى في سلسلة DevOps والسحابة واختر الخطوة التالية حسب الفجوة.

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

تابع السلسلة

استخدم الروابط كمسار تعلم، لكن نفذ كل قرار على بيانات النظام الفعلية.

المصادر وتاريخ المراجعة

آخر مراجعة: 2026-08-28. راجع الأسعار والحصص وتوافر الميزات في المنطقة مباشرة قبل التنفيذ.

اقرأ أيضاً