حرف C

التكامل المستمر والتسليم/النشر المستمر

CI/CD

آخر تحديث: 2026-10-24
مستوى الشرح اختر المستوى التقني المناسب لك

الشرح المبسط

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

الشرح التقني المتقدم

يُعد مصطلح CI/CD العمود الفقري لثقافة التطوير والعمليات (DevOps) في بيئات لينكس (Linux Environments). يهدف هذا النهج إلى أتمتة دورة حياة تطوير البرمجيات بالكامل، مما يقلل من التدخل البشري ويحد من الأخطاء الناتجة عن عمليات الدمج والنشر اليدوية.

المفاهيم الأساسية لتقنية CI/CD

ينقسم هذا النهج إلى مرحلتين أساسيتين تعملان بتناغم تام داخل النظام (System):

التكامل المستمر (Continuous Integration): هي عملية دمج تغييرات الشيفرة المصدرية (Source Code) بانتظام وبشكل آلي في مستودع مركزي (Repository). يقوم الخادم فوراً بتشغيل عمليات البناء (Build) والاختبارات الآلية للتحقق من سلامة الأكواد وعدم تعارضها مع النظام الحالي.

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

إعداد وكيل التنفيذ (Runner) في خوادم لينكس

لتشغيل مسار العمل (Pipeline)، نحتاج إلى أداة تعمل كخدمة خلفية (Daemon) تستمع للتغييرات في المستودع وتنفذ الأوامر المطلوبة. من أشهر هذه الأدوات في عالم مفتوح المصدر وكيل جيت لاب (GitLab Runner).

أمر تحديث المستودعات وتثبيت الوكيل على التوزيعات المبنية على دبيان (Debian):

sudo apt-get update && sudo apt-get install gitlab-runner

بعد التثبيت، نستخدم الأمر gitlab-runner register لربط الخادم بالمستودع، مما يؤدي إلى توليد ملف إعدادات (Configuration File) يتم حفظه عادة في المسار /etc/gitlab-runner/config.toml.

يمر مسار العمل الآلي عادة بالمراحل التالية لتحقيق أفضل النتائج:

  • مرحلة البناء (Build): تجميع الكود المصدري وتحويله إلى حاويات دُوكر (Docker Containers) لتسهيل نقله وتشغيله.
  • مرحلة الاختبار (Test): تشغيل أوامر برمجية لفحص الكود، مثل الأمر make test، لضمان استقرار التطبيق.
  • مرحلة النشر (Deploy): نقل الحاويات أو الملفات النهائية إلى الخوادم الحية لتعمل عليها بشكل مستقر.

ملاحظة ختامية: الصورة الكبرى (نصيحة احترافية)

لضمان أقصى درجات الأمان في خوادم لينكس، تأكد دائماً من تشغيل أدوات CI/CD باستخدام مستخدم بصلاحيات محدودة (Non-root User)، وقم بتخزين كلمات المرور والمفاتيح السرية كمتغيرات بيئة (Environment Variables) مشفرة بدلاً من كتابتها كنصوص صريحة داخل ملفات مسار العمل.

المصادر المعتمدة :