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

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

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

تساعد القدرة على أتمتة المراحل المختلفة لمسار عمل CI/CD فرق التطوير على تحسين الجودة، والعمل بشكل أسرع، وتحسين مقاييس DevOps الأخرى.

بينما يشير مسار عمل CI/CD إلى سير عمل DevOps المرن، فإن مصطلح CI/CD يرمز إلى الممارسات المشتركة للتكامل المستمر والتسليم المستمر.

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

يتيح مسار عمل CI/CD لفرق DevOps كتابة الكود البرمجي، ودمجه، وتشغيل الاختبارات، وتسليم الإصدارات، ونشر التغييرات على البرمجيات بشكل تعاوني وفي الوقت الفعلي. وبينما تعد أتمتة إصدارات البرمجيات—بدءًا من الاختبار الأولي وحتى النشر النهائي—ميزة جوهرية لمسار عمل CI/CD، فإن الفوائد الأخرى تشمل ما يلي:

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

• خفض التكاليف: إن السرعة في عمليات التطوير والاختبار والإنتاج (والتي تسهلها الأتمتة) تعني قضاء وقت أقل في عملية التطوير. تؤدي هذه العملية إلى خفض التكاليف مقارنة بالتطوير التقليدي للبرمجيات.

• حلقات التغذية الراجعة المستمرة: يمثل مسار عمل CI/CD دورة مستمرة تشمل : البناء، والاختبار، والنشر. تتيح حلقات التغذية الراجعة للمطورين اتخاذ إجراءات سريعة وتحسين الكود البرمجي في كل مرة يخضع فيها ذلك الكود للاختبار.

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

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

• تحسين تعاون الفريق وتكامل النظام: يمكن لكل فرد في الفريق تغيير الكود البرمجي، والاستجابة للتغذية الراجعة، والتعامل السريع مع أي مشكلات.

يتكون مسار عمل CI/CD من 3 منهجيات متصلة:

• التكامل المستمر
• التسليم المستمر
• النشر المستمر

تبدأ عملية CI/CD بالتكامل المستمر (CI)، حيث يقوم المطورون بإرسال أكوادهم البرمجية إلى مستودعات مركزية تُدار بواسطة أنظمة التحكم في الإصدارات (VCSs). يُتيح التكامل المستمر للمطورين العمل بشكل مستقل، من خلال إنشاء "فرع" خاص بهم لكتابة الكود وتطبيق تغييرات صغيرة.

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

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

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

الخطوة التالية في مسار العمل هي التسليم المستمر (CD)، والتي تضع تغييرات لكود البرمجي التي تم التحقق من صحتها في مرحلة التكامل المستمر داخل بيئات محددة أو مستودعات الكود، مثل GitHub. وهنا، يمكن لفريق العمليات نشرها في بيئة إنتاج حية.

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

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

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

يتعامل كل من التسليم المستمر والنشر المستمر مع الأتمتة في مراحل متقدمة من مسار العمل مقارنة بالتكامل المستمر وغالبًا ما يُستخدمان بالتبادل.

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

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

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

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

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

لإلقاء نظرة عن كثب على الفرق بين التسليم المستمر والنشر المستمر، شاهد هذا الفيديو.

يُعد مسار عمل تعلم الآلة عبارة عن سلسلة من خطوات معالجة البيانات ونمذجتها المترابطة، والمصممة لأتمتة وتوحيد وتبسيط عملية بناء نماذج تعلم الآلة وتدريبها وتقييمها ونشرها.

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

وفقًا لـ Kings Research، قُدّر حجم سوق تعلم الآلة العالمي بنحو 26.06 مليار دولار أمريكي في عام 2023، ومن المتوقع أن ينمو من 35.44 مليار دولار في عام 2024 إلى 328.89 مليار دولار بحلول عام 2031، مسجلاً معدل نمو سنوي مركب بنسبة 37.47% خلال الفترة المتوقعة.¹

تتكامل مسارات عمل تعلم الآلة مع ممارسات DevOps لإتاحة CI/CD لنماذج تعلم الآلة. ويُشار إلى هذا التكامل باسم عمليات تعلم الآلة (MLOps)، ما يساعد فرق علوم البيانات على إدارة تعقيدات إدارة تنسيق تعلم الآلة بفعالية.

بدءًا من الكود المصدري وحتى بيئة الإنتاج، تشمل هذه المراحل دورة حياة التطوير وسير العمل لمسار عمل CI/CD:

• البناء
• الاختبار
• التسليم
• النشر

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

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

هنا، يتم إرسال قاعدة الكود المعتمدة إلى بيئة الإنتاج. هذه المرحلة تكون مؤتمتة بالكامل في النشر المستمر، بينما تكون مؤتمتة في التسليم المستمر بعد الحصول على موافقة المطور.

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

عند اختيار أدوات CI/CD، يجب أن ينصب التركيز على تحسين وأتمتة عملية تطوير البرمجيات. يستخدم مسار عمل CI/CD الفعال أدوات مفتوحة المصدر للتكامل والاختبار والنشر. كما أن الإعداد الصحيح لعملية CI/CD يؤثر أيضًا في نجاح مسار تطوير البرمجيات.

أداة CI/CD مفتوحة المصدر الأكثر شيوعًا هي Jenkins. تُعد Jenkins خادم تكامل مستمر مؤتمت ومكتوب بلغة Java ويُستخدم لأتمتة خطوات CI/CD وإعداد التقارير. وتشمل الأدوات الأخرى مفتوحة المصدر للتكامل كلاً من Travis CI وCircleCI.

بالإضافة إلى الأدوات مفتوحة المصدر، يقدم جميع مزودي خدمات الحوسبة السحابية الرئيسيين —مثل Google Cloud، وIBM Cloud®، وMicrosoft Azure وAmazon Web Services (AWS)—مجموعات أدوات CI/CD السحابية ومساراتها وتكاملاتها.

تساعد بيئات التطوير المتكاملة (IDE)، مثل GitHub أو AWS CodeCommit، المطورين على إنشاء الحزم البرمجية وصيانتها وتتبعها. وفي الوقت نفسه، تسعى منصات مثل GitLab إلى توفير بيئة التطوير المتكاملة ضمن منصة شاملة تتضمن أدوات أخرى.

عند العمل في بيئة سحابية، تستخدم فرق DevOps السحابية الأصل الحاويات مثل Docker لتعبئة التطبيقات وشحنها، كما تستخدم أدوات إدارة وتنظيم الحاويات مثل Kubernetes. وعلى الرغم من أن Kubernetes لا تقتصر حصريًا على مسار عمل CI/CD، إلا أنها تُستخدم في العديد من مهام سير عمل CI/CD.

يركز أمن CI/CD على الممارسات والعمليات والتقنيات التي تطبق وتدير تدابير الأمن والامتثال عبر مسار عمل CI/CD.

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

قد لا يواكب الأمن الإصدارات السريعة مع اعتماد المطورين لممارسات agile وDevOps، ما حفّز تطور مفهوم DevSecOps، وهو اختصار يرمز إلى التطوير و الأمن و العمليات. يقوم نظام DevSecOps بأتمتة دمج ممارسات أدوات الأمن فور ظهورها ضمن مسارات عمل التكامل المستمر (CI) والتسليم المستمر (CD).

تشمل ممارسات DevSecOps اختبارات shift-left وshift-right. يتضمن اختبار shift left دمج اختبارات الأمن وممارسات التطوير الحيوية الأخرى في مرحلة مبكرة من دورة حياة تطوير البرمجيات (SDLC). بينما يتضمن اختبار Shift-right إجراء الاختبارات في مرحلة لاحقة من عملية التطوير، وعادةً ما يكون ذلك في بيئات الإنتاج. وتكمل هذه الأساليب بعضها البعض من خلال توزيع مسؤولية الاختبار على مدار دورة حياة تطوير البرمجيات بالكامل.