ما هو التكامل المستمر والتسليم المستمر (CI/CD)؟

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

ما هو التكامل المستمر والتسليم المستمر (CI/CD)؟

التكامل المستمر (Continuous Integration) ممارسة يدمج فيها الفريق تغييراته في فرع مشترك عدة مرات يوميًا، ويشغّل عند كل دمج بناءً واختبارات آلية. والهدف كشف التعارض والأخطاء بعد دقائق من كتابة الشيفرة، لا بعد أسابيع.

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

ويجمع اختصار CI/CD الممارستين، ويُستخدم أيضًا اسمًا لخط الأنابيب نفسه: سلسلة الخطوات التي تحوّل الالتزام (Commit) في المستودع إلى إصدار يعمل. ويُبنى الخط على مبدأ واحد: ما اختُبر هو ما يُنشر، بالضبط.

كيف يعمل خط الأنابيب (Pipeline)؟

يبدأ الخط بمُشغّل (Trigger) يستجيب لالتزام جديد أو طلب دمج أو جدول زمني. ثم تُجلب الشيفرة إلى بيئة نظيفة، وتُثبّت الاعتماديات بإصدارات مقفلة، ويُبنى الناتج مرة واحدة، وتتفرع عنه الخطوات التالية:

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

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

ما أنواع الاختبارات التي تحمي الخط؟

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

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

ويُضاف إلى ذلك التحليل الساكن للشيفرة، وفحص الاعتماديات، واختبارات الأداء الدورية. والبوابة (Gate) لا معنى لها إن اعتاد الفريق تجاوزها، فالفشل المتكرر بلا سبب حقيقي يعلّم الناس تجاهل اللون الأحمر، ويحوّل الحماية إلى إجراء شكلي.

كيف تُنشر الإصدارات بأمان؟

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

والنشر الأزرق والأخضر (Blue-Green) يجهّز بيئة كاملة موازية، ويحوّل حركة المرور إليها بعد التحقق، فيصبح الرجوع مسألة تحويل سريع. أما النشر الكناري (Canary) فيوجّه نسبة صغيرة من الحركة إلى النسخة الجديدة، ويراقب مؤشرات الخطأ وزمن الاستجابة قبل التوسع.

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

كيف يعمل التراجع (Rollback)؟

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

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

ويفضّل كثير من الفرق التراجع إلى الأمام (Roll-forward): إصلاح العيب ونشر نسخة جديدة بدل العودة، لأن العودة قد تعيد بيانات لم تعد متوافقة. ويُبنى القرار على نوع العطل: خطأ في الشيفرة، أم في البيانات، أم في التكوين. ويكتب الفريق إجراءً مسبقًا يحدد من يقرر، وكيف يتحقق، وما الخطوة التالية بعد العودة.

كيف نحمي الأسرار في الخط؟

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

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

ما حدود CI/CD ومتى تقلق؟

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

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

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

أسئلة شائعة

مقالات ذات صلة

• ما هو DevOps؟
• ما هو Docker؟
• ما هو Kubernetes؟
• ما هي المراقبة (Observability)؟ السجلات والمقاييس والتتبعات

المصادر

• IBM Think, What is CI/CD? — تحديث 13 مارس 2026
• NIST, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (SP 800-204D) — فبراير 2024
• NIST, Secure Software Development Framework (SP 800-218) — فبراير 2022
• AWS, What is DevOps? — 2026

صورة الغلاف: Wasiul Bahar / Wikimedia Commons، بموجب رخصة CC BY-SA.