ما الذي يُشغل فعليًا خط أنابيب CI/CD؟

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

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

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

عندما يدفع المطور كودًا

المشغّل الأكثر شيوعًا هو الالتزام (commit) المدفوع إلى مستودع مشترك. ينهي المطور تغييرًا، يلتزمه محليًا، ويدفعه إلى GitHub أو GitLab أو Bitbucket. يرسل المستودع خطاف ويب (webhook) إلى نظام CI/CD، ويبدأ خط الأنابيب.

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

يُظهر الرسم البياني أدناه كيف يتفرع مشغّل الدفع بناءً على البيانات الوصفية للالتزام:

إليك كيف يمكنك تعريف مشغّل دفع كهذا في سير عمل GitHub Actions:

name: CI Pipeline
on:
  push:
    branches:
      - main
      - 'feature/**'
    paths-ignore:
      - 'README.md'
      - 'docs/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
flowchart TD Push[Git Push] --> Webhook[Webhook to CI/CD] Webhook --> Inspect[Inspect Commit Metadata] Inspect --> Branch{Branch?} Branch -- feature --> Unit[Run Unit Tests & Lint] Branch -- main --> Full[Run Full Test Suite] Inspect --> Files{Files Changed?} Files -- code only --> Unit Files -- includes docs --> Skip[Skip Tests] Files -- mixed --> Full

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

عندما يتم دمج طلب سحب (Pull Request)

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

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

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

عندما تقول الساعة ذلك

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

تشمل حالات الاستخدام الشائعة:

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

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

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

عندما يضغط شخص ما على الزر

تمنح المشغّلات اليدوية (Manual triggers) للإنسان الكلمة الأخيرة. بدلاً من أن يبدأ خط الأنابيب تلقائيًا، يقوم شخص ما بتسجيل الدخول إلى نظام CI/CD وينقر على "تشغيل" أو "نشر".

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

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

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

لماذا البيانات الوصفية أكثر أهمية مما تعتقد

يحمل كل مشغّل معلومات. يحمل مشغّل الالتزام تجزئة الالتزام واسم الفرع والمؤلف. يحمل مشغّل الدمج رقم طلب السحب وأسماء المراجعين. يحمل المشغّل اليدوي اسم المشغل وسبب إعلانه.

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

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

قائمة مراجعة سريعة لاختيار المشغّلات

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

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

الخلاصة

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