CI/CD: المفاهيم وخط الأنابيب

8 دقيقة

جدول المحتويات


1 — ما هو CI/CD؟

CI/CD هو العمود الفقري التقني لـ DevOps. مجموعة الممارسات التي تؤتمت المسار بين «الشفرة التي كتبها مطوّر» و«التطبيق الذي يعمل في الإنتاج».

الاختصارالاسمفي جملة واحدة
CIالتكامل المستمر (Continuous Integration)ندمج الشفرة ونختبرها مراراً وتلقائياً.
CDالتسليم المستمر (Continuous Delivery)الشفرة المختبَرة دائماً جاهزة للنشر (وضع الإنتاج يدوي).
CDالنشر المستمر (Continuous Deployment)الشفرة المختبَرة تذهب تلقائياً إلى الإنتاج.

بلا CI/CD، تسليم برمجيات يشبه الانتقال يدوياً: بطيء، ومرهق، وخطر. مع CI/CD، هو سير ناقل آلي: تضع الشفرة في طرف، والتطبيق يصل جاهزاً في الطرف الآخر.

تمرين مصغّر — اربط كل اختصار بتعريفه: (1) CI، (2) Continuous Delivery، (3) Continuous Deployment.

عرض الحل

(1) CI = دمج + بناء + اختبارات آلية متكررة. (2) Continuous Delivery = دائماً جاهز للنشر، زر يدوي للإنتاج. (3) Continuous Deployment = وضع الإنتاج تلقائي بعد نجاح الاختبارات.

↑ العودة إلى الأعلى


2 — CI — التكامل المستمر

التكامل المستمر هو الدمج المتكرر لشفرة جميع المطوّرين في فرع مشترك، والتحقق التلقائي من كل دمج عبر بناء واختبارات.

لماذا «مستمر»؟

بلا CIمع CI
ندمج الكل في نهاية الشهر ← تعارضات كبيرة مؤلمةندمج عدة مرات في اليوم ← تعارضات صغيرة سهلة
تُكتشَف الأخطاء متأخراًتُكتشَف الأخطاء خلال دقائق
«كان يعمل على جهازي»بناء قابل لإعادة الإنتاج على الخادم

تشبيه: ترتيب المطبخ أولاً بأول (CI) بدل انتظار أن يتسخ كل شيء (تكامل «انفجار كبير»). الجهد الصغير المتكرر يتجنّب الكارثة النادرة.

تمرين مصغّر — مطوّر يحتفظ بشفرته 3 أسابيع دون دمج، ثم يحاول دمجاً كبيراً. أي مبدأ تكامل مستمر لم يحترمه، وما النتيجة المحتملة؟

عرض الحل

لم يدمج مراراً. النتيجة المحتملة: تعارض دمج ضخم وصعب الحل، وأخطاء تُكتشَف متأخراً جداً. توصي CI بدمج صغير متكرر.

↑ العودة إلى الأعلى


3 — CD — التسليم مقابل النشر المستمر

يشبه «CD» أحدهما الآخر ويختلفان في نقطة واحدة: من يضغط زر وضع الإنتاج.

Continuous DeliveryContinuous Deployment
وضع الإنتاجيدوي (إنسان ينقر)تلقائي
الرقابةقرار بشري نهائيبلا تدخل
مثالي لـقطاعات منظَّمة، إصدارات مخطَّطةفرق ناضجة، تغطية اختبارات قوية

Continuous Delivery = السيارة مركونة أمام الباب، جاهزة، المفاتيح في الكونتاكت؛ أنت تقرر متى تنطلق. Continuous Deployment = السيارة الذاتية تنطلق وحدها ما إن تصبح جاهزة.

تمرين مصغّر — بنك يريد أن يوافق مسؤول على كل وضع إنتاج. أي «CD» يختار؟

عرض الحل

Continuous Delivery: يجعل خط الأنابيب الإصدار جاهزاً تلقائياً، لكن وضع الإنتاج يبقى قراراً بشرياً (موافقة المسؤول).

↑ العودة إلى الأعلى


4 — خط أنابيب CI/CD خطوة بخطوة

خط الأنابيب (pipeline) سلسلة مراحل آلية تُسمّى stages تحوّل شفرة المصدر إلى تطبيق منشور. إذا فشلت مرحلة، يتوقف الخط ويُبلَّغ الفريق.

المرحلةالدورمثال أداة
Checkoutاسترجاع الشفرة من GitGit
Buildالتجميع / التركيبMaven، npm، javac
Testالتحقق الآليJUnit، pytest
Packageإنتاج أثر قابل للتسليم.jar، صورة Docker
Stagingالنشر في ما قبل الإنتاجخادم اختبار
Deployالوضع في الإنتاجخادم / سحابة

مبدأ «fail fast»: نضع المراحل السريعة والرخيصة (تجميع، اختبارات وحدية) أولاً. لا فائدة من النشر إن كانت الشفرة لا تُجمَع أصلاً.

تمرين مصغّر — بأي ترتيب تضع هذه المراحل: Deploy، Build، Test، Checkout؟

عرض الحل

CheckoutBuildTestDeploy. نسترجع الشفرة، نجمّعها، نختبرها، ولا ننشر إلا إذا كان كل شيء أخضر.

↑ العودة إلى الأعلى


5 — مثال ملموس من الطرف إلى الطرف

نتابع مسار سطر شفرة واحد صحّحته مطوّرة، ليلى، في تطبيق ويب.

التسلسل خطوة بخطوة:

  1. تصحّح ليلى خطأ وتنفّذ git push.
  2. webhook يُعلم خادم CI/CD بوجود شفرة جديدة.
  3. يُجمّع خط الأنابيب، ويشغّل 124 اختباراً (كلها خضراء)، ثم يغلف الإصدار v1.4.1.
  4. يُنشَر الإصدار تلقائياً.
  5. بعد ست دقائق من الدفع، التصحيح على الخط — بلا تدخل يدوي.

قارن: قبل CI/CD، كان التصحيح نفسه يتطلب وضع إنتاج مخطَّطاً، مساءً، يدوياً، مع توتر «ليته يعمل». هنا روتين بست دقائق.

تمرين مصغّر — في الخطوة 3، يفشل اختباران من 124. ماذا يفعل خط الأنابيب، وهل يذهب الإصدار إلى الإنتاج؟

عرض الحل

يتوقف خط الأنابيب عند مرحلة Test، ويبلّغ ليلى، ولا ينشر. يبقى الإنتاج على الإصدار المستقر السابق. هذا مبدأ «fail fast» الذي يحمي الإنتاج.

↑ العودة إلى الأعلى


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

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

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

عرض الحل
  1. كل نشر يحتوي قليلاً من الشفرة ← الخطأ سهل التحديد. 2) التراجع بسيط (قليل من التغييرات للإلغاء). النشر الشهري الكبير يجمع على العكس كثيراً من المخاطر دفعة واحدة.

↑ العودة إلى الأعلى


7 — اختبار — مفاهيم CI/CD

السؤال 1: ماذا يعني « CI »؟

a) Code Inspection

b) Continuous Integration

c) Container Initialization

d) Central Infrastructure

عرض الحل

الإجابة: b)Continuous Integration: دمج وتحقق آلي متكرر للشفرة.


السؤال 2: ما الفرق بين Continuous Delivery و Continuous Deployment؟

a) لا فرق، هما مترادفان

b) في Delivery وضع الإنتاج يدوي؛ في Deployment تلقائي

c) Deployment لا يجري اختبارات

d) Delivery ينشر تلقائياً

عرض الحل

الإجابة: b) — كلاهما يجهّز إصداراً جاهزاً؛ وحده وضع الإنتاج يختلف (يدوي مقابل تلقائي).


السؤال 3: ماذا يحدث إذا فشلت مرحلة Test في خط أنابيب؟

a) يستمر الخط رغم ذلك حتى الإنتاج

b) يتوقف الخط ويُبلَّغ الفريق

c) تُحذف الشفرة من المستودع

d) يعيد الخط البدء بلا نهاية

عرض الحل

الإجابة: b) — مبدأ «fail fast»: الفشل يوقف الخط ويطلق تنبيهاً؛ لا شيء يذهب إلى الإنتاج.


السؤال 4: ما الأثر (artefact) في خط أنابيب؟

a) خطأ أُدخل بالخطأ

b) نتيجة البناء المغلفة (مثال .jar، صورة)

c) رسالة في السجلات

d) مستخدم للنظام

عرض الحل

الإجابة: b) — الأثر هو المخرج الذي ينتجه البناء، جاهز للنشر.


السؤال 5: لماذا يجعل النشر المتكرر عمليات النشر أكثر أماناً؟

a) لأن كل نشر أصغر، إذن أسهل تشخيصاً وإلغاءً

b) لأننا نحذف الاختبارات

c) لأن الخوادم تصبح أقوى

d) لأن المستخدمين لا يلاحظون

عرض الحل

الإجابة: a) — تغييرات صغيرة متكررة تقلّل سطح المخاطرة وتسهّل التراجع.

↑ العودة إلى الأعلى


8 — تطبيق عملي — تصميم أول خط أنابيب

المطلوب

فريق يطوّر تطبيقاً بلغة Java. صمّم (على الورق / بخط أنابيب شبه رمزي) مراحل خط أنابيب CI/CD لهذا التطبيق، مبيناً لكل مرحلة: اسمها، ودورها، وما الذي يجب أن يوقف الخط. حدّد أيضاً إن كنت توصي بـ Continuous Delivery أو Continuous Deployment، ولماذا.


تصحيح مقترح

الترتيبالمرحلةالدورشرط التوقف
1Checkoutاسترجاع الشفرة من Gitالمستودع غير متاح
2Buildالتجميع بـ Maven (mvn package)خطأ تجميع
3Testتشغيل اختبارات JUnitفشل اختبار
4Packageإنتاج أثر .jar / صورةفشل التغليف
5Stagingالنشر في ما قبل الإنتاجفشل بدء التطبيق
6Deployالوضع في الإنتاجرفض التحقق اليدوي

الخيار الموصى به للبداية: Continuous Delivery.

التبرير: ما دامت تغطية الاختبارات غير ناضجة، نبقي تحققاً بشرياً قبل الإنتاج (Delivery). عندما يثق الفريق باختباراته الآلية، يمكن الانتقال إلى Continuous Deployment (وضع إنتاج تلقائي).

المخطط المتوقع:

↑ العودة إلى الأعلى


9 — الخلاصة

النقاط التي يجب تذكّرها

  1. CI/CD = أتمتة المسار من الشفرة إلى الإنتاج، القلب التقني لـ DevOps.
  2. CI: الدمج والاختبار مراراً وتلقائياً.
  3. CD: Delivery (جاهز للنشر، زر يدوي) مقابل Deployment (وضع إنتاج تلقائي).
  4. خط الأنابيب يسلسل مراحل؛ الفشل يوقف الكل (fail fast).
  5. النشر المتكرر والصغير = مخاطرة أقل، تغذية راجعة سريعة، تراجع سهل.

ما يلي

الدرس 05 — Git: التثبيت والإعداد: تثبيت Git وإعداده على جهازك قبل أول مستودع.

↑ العودة إلى الأعلى


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

دورة من إعداد الدكتور هيثم رحومة — تطوير ونشر حلول البيانات