ما هو CI/CD؟ التكامل والتسليم المستمران بشرح مبسط
CI/CD أسلوب لإطلاق البرمجيات حيث يُبنى كل تغيير في الكود ويُختبر تلقائياً، وإذا نجح يُجهَّز للإصدار أو يُطلق. CI (التكامل المستمر) يعني أن التغييرات تُدمج بكثرة وتُفحص بالاختبارات الآلية في كل مرة. أما CD (التسليم أو النشر المستمر) فيعني أن التغييرات الناجحة تُحزم وتُدفع نحو المستخدمين بقليل من العمل اليدوي أو دون عمل يدوي.
الفكرة بسيطة: اكتشف الأخطاء بعد دقائق من ارتكابها، لا بعد أسابيع حين يجدها عميل.
لماذا يهم CI/CD عند البناء بالذكاء الاصطناعي؟
أدوات البناء بالذكاء الاصطناعي تُجري تغييرات في الكود بسرعة. طلب واحد قد يمس عشرة ملفات. هذه السرعة رائعة، حتى يكسر تغيير في صفحة الدفع صفحة تسجيل الدخول بهدوء، ولا يلاحظ أحد ذلك إلا عندما يراسلك مستخدم.
CI/CD هو شبكة الأمان لهذا تحديداً. بدلاً من الثقة بأن كل تغيير سليم، يشغّل خط الأتمتة الفحوصات نفسها في كل مرة:
- هل ما زال التطبيق يُبنى دون أخطاء؟
- هل تنجح الاختبارات الآلية؟
- هل يلتزم الكود بقواعد المشروع (الأنواع، والتنسيق، وفحوصات الأمان)؟
إذا فشل أي فحص، يُوقف التغيير قبل أن يصل إلى المستخدمين. كلما كانت التغييرات في كودك أسرع، زادت قيمة فحص لا يتعب ولا يتخطى خطوة.
تشبيه من الحياة اليومية
فكّر في مخبز يبيع الخبز للمتاجر كل صباح.
- بدون CI/CD، يعمل كل خباز على تعديلات وصفته لأسبوع، ثم يُدمج الجميع كل شيء ليلة الجمعة ويأملون أن يرتفع الخبز. وعندما لا يرتفع، لا يعرف أحد أي تغيير سبب ذلك.
- مع CI، يُخبز كل تعديل صغير في وصفة تجريبية فوراً ويُفحص: الطعم والوزن والشكل. يُكتشف التغيير السيئ في اليوم نفسه، ويُعرف بالضبط أيهم كان.
- مع CD، ترحل الأرغفة التي تجتاز الفحص مباشرة إلى شاحنة التوصيل، معبأة ومُعنونة بالطريقة نفسها كل مرة، بدلاً من أن يعبئها أحد يدوياً في الخامسة صباحاً.
الفحص لا يجعل الخبازين أفضل، لكنه يجعل أخطاءهم رخيصة.
كيف يعمل خط CI/CD؟
الـ خط الأتمتة (pipeline) قائمة من الخطوات تشغّلها خدمة CI/CD تلقائياً عند حدوث شيء ما، عادةً عندما يُرفع الكود إلى مستودع مثل GitHub. يبدو خط نموذجي كالتالي:
| الخطوة | ما يحدث | ما الذي تكتشفه |
|---|---|---|
| 1. المُشغِّل (Trigger) | يُرفع الكود أو يُفتح طلب دمج (pull request) | — |
| 2. التثبيت | يُنزّل جهاز جديد الكود وحزمه التابعة | حزم ناقصة أو معطلة |
| 3. البناء | يُترجم التطبيق أو يُجمّع | أخطاء الصياغة والأنواع، والاستيرادات المكسورة |
| 4. الاختبار | تعمل الاختبارات الآلية | الميزات التي لم تعد تعمل |
| 5. الفحوصات | تحليل الأسلوب (linting)، والتنسيق، وفحوصات الأمان | مشاكل التنسيق، وحزم معروفة بثغرات، ومفاتيح مسرّبة |
| 6. النشر إلى بيئة الاختبار (staging) | يُنقل التطبيق إلى نسخة اختبار من الإنتاج | مشاكل لا تظهر إلا في بيئة حقيقية |
| 7. النشر إلى الإنتاج | يصبح التطبيق متاحاً، تلقائياً أو بعد موافقة | — |
تعمل كل خطوة على جهاز نظيف، لا على حاسوب أحدهم، فلا يعود «إنه يعمل على جهازي» عذراً مقبولاً. إذا فشلت خطوة، يتوقف الخط ويُبلغ من قام بالتغيير.
تُعرَّف الخطوات في ملف إعداد يعيش مع الكود. في GitHub Actions، مثلاً، يكون ذلك ملف YAML في مجلد .github/workflows داخل المستودع.
التسليم المستمر مقابل النشر المستمر
كلمة "CD" ملتبسة، ويستخدمها الناس بالمعنيين:
| التسليم المستمر | النشر المستمر | |
|---|---|---|
| تعمل الاختبارات تلقائياً | نعم | نعم |
| تُحزم نسخة الإصدار تلقائياً | نعم | نعم |
| تُطلق للمستخدمين تلقائياً | لا، شخص يضغط زر "إطلاق" | نعم، كل تغيير ناجح يُطلق |
| مناسب لـ | معظم الفرق الصغيرة، والتطبيقات ذات المستخدمين الدافعين | الفرق ذات التغطية الاختبارية القوية والمراقبة الجيدة |
النشر المستمر يعمل جيداً فقط إذا كانت الاختبارات جيدة. إذا كانت اختباراتك لا تغطي الدفع، فسينشر النشر المستمر صفحة دفع معطلة بكل سرور.
مثال عملي: تطبيق حجوزات مع خط أتمتة
لنفترض أن لديك تطبيق حجوزات لصالون، وأن كوده في مستودع GitHub. تطلب من أداة بناء بالذكاء الاصطناعي: «أضف خصم 10% للعملاء الجدد.»
- يُرفع التغيير إلى فرع جديد، ويُفتح طلب دمج (pull request).
- يبدأ خط الأتمتة. يثبّت الحزم ويبني التطبيق، وينجح ذلك.
- يشغّل الاختبارات. يفشل اختبار واحد، وهو «العميل العائد يدفع السعر الكامل»، لأن الخصم يُطبَّق على الجميع.
- يظهر في طلب الدمج علامة حمراء. لا يمكن دمج التغيير.
- تطلب من الذكاء الاصطناعي إصلاح الأمر. يرفع تصحيحاً، فيعمل الخط مجدداً وتنجح كل الفحوصات.
- يُدمج التغيير. ينشره الخط إلى بيئة الاختبار (staging)، حيث تجرب حجزاً تجريبياً.
- توافق، فينشر إلى الإنتاج.
بدون الخط، كان الخطأ في الخطوة 3 سيقع على محافظ عملائك.
مصطلحات أساسية
| المصطلح | المعنى |
|---|---|
| Pipeline (خط الأتمتة) | التسلسل الآلي للخطوات الذي يعمل على كل تغيير. |
| Build (البناء) | تحويل الكود المصدري إلى شيء يمكن تشغيله. |
| Automated test (اختبار آلي) | كود يتحقق من أن كوداً آخر يفعل ما يجب. |
| Pull request (PR) (طلب دمج) | تغيير مقترح يراجعه الآخرون والخط قبل دمجه. انظر ما هو GitHub. |
| Branch (الفرع) | خط منفصل من التغييرات، حتى لا يؤثر العمل الجاري على الكود الرئيسي. |
| Staging (بيئة الاختبار) | نسخة خاصة من تطبيقك تحاكي الإنتاج، لفحص التغييرات قبل أن يراها المستخدمون. |
| Production (الإنتاج) | التطبيق الحي الذي يستخدمه المستخدمون. |
| Rollback (التراجع) | العودة إلى النسخة السابقة التي كانت تعمل عندما يسوء إصدار ما. |
| Green / red build (بناء أخضر / أحمر) | تشغيل خط نجح / فشل. |
مفاهيم خاطئة شائعة
- «CI/CD يعني أن تطبيقي مُختبر.» الخط لا يشغّل إلا الاختبارات التي تملكها. إذا لم تكن هناك اختبارات، فكل ما يثبته CI هو أن التطبيق يُبنى، ولا شيء أكثر. اطلب من الذكاء الاصطناعي كتابة اختبارات للتدفقات الأهم.
- «CI/CD للشركات الكبيرة فقط.» أدوات الاستضافة مثل GitHub Actions تحتاج إلى ملف إعداد قصير، وتستخدمها الفرق الصغيرة طوال الوقت. الجهد يكمن في الاختبارات لا في الأداة.
- «النشر التلقائي يعني أن لا أحد يتحقق من شيء.» الخطوط الجيدة تضيف فحوصات ولا تحذفها. كثير من الفرق تحتفظ بخطوة موافقة بشرية قبل الإنتاج.
- «إذا كان الخط أخضر فالتطبيق يعمل.» هذا يعني أن الفحوصات الآلية نجحت. ما زال عليك تجربة التغيير بنفسك، ويفضل في معاينة أو على بيئة الاختبار.
- «CI/CD يغني عن النسخ الاحتياطية.» لا. قد يمر ترحيل قاعدة بيانات سيء من الاختبارات ويتلف البيانات الحقيقية. احتفظ بنسخ احتياطية وطريقة للتراجع.
ماذا تسأل أداة البناء بالذكاء الاصطناعي؟
- «اكتب اختبارات آلية لتسجيل الاشتراك وتسجيل الدخول والدفع، وأرني كيف أشغّلها.»
- «أعدّ سير عمل في GitHub Actions يثبّت الحزم ويبني التطبيق ويشغّل الاختبارات في كل طلب دمج.»
- «أضف فحص الأنواع وأداة تحليل الأسلوب (linter) إلى الخط، واجعله يفشل عند وجود أخطاء.»
- «اشرح بلغة بسيطة ما تفعله كل خطوة في الخط.»
- «ماذا يحدث إذا فشل النشر في منتصفه؟ كيف أتراجع؟»
- «تحقق من أنه لا توجد أسرار مكتوبة في الكود داخل المستودع أو مطبوعة في سجلات الخط.»
إذا كان تطبيقك يستخدم مفاتيح API، فالخط يحتاجها أيضاً، ويجب تخزينها كأسرار مشفّرة في أداة CI، لا في ملف الإعداد. انظر متغيرات البيئة والأسرار.
CI/CD وMythex
لا يشغّل Mythex خط CI لك، لكنه يغطي عدة احتياجات مشابهة بطريقته الخاصة:
- نقاط الحفظ (Checkpoints). بعد كل دورة ناجحة للوكيل يحفظ Mythex نقطة حفظ في git، وخيار العودة إلى هذه النقطة (Revert to this point) يعيد المشروع إلى الوراء إذا سار تغيير بشكل خاطئ. انظر المحادثة.
- اختبار التطبيق (App Testing). اكتب
/testفيقوم الوكيل بالتنقل في معاينتك الحية كمستخدم، ويُبلغ عن التدفقات المعطلة، وهذا مفيد قبل كل نشر. انظر اختبار التطبيق. - النشر خطوة مقصودة. تظهر التغييرات أولاً في المعاينة الخاصة، ولا يتحدث تطبيقك العام إلا عند النشر مجدداً، وهذا أقرب إلى التسليم المستمر منه إلى النشر المستمر.
- مزامنة GitHub (Pro). زامن المشروع مع مستودع GitHub، وستستطيع إضافة سير عمل GitHub Actions الخاص بك لتشغيل الاختبارات مع كل دفعة. انظر GitHub والتصدير.
لقائمة ما يجب اختباره يدوياً قبل الإطلاق، انظر كيف تختبر تطبيقك قبل الإطلاق، ولإدارة الإصدارات، انظر كيف تستخدم Git مع تطبيق مبني بالذكاء الاصطناعي.
الأسئلة
ماذا تعني CI/CD؟
CI تعني التكامل المستمر (continuous integration): تُدمج تغييرات الكود بكثرة، ويُبنى كل تغيير ويُختبر تلقائياً. وCD تعني التسليم المستمر (continuous delivery) أو النشر المستمر (continuous deployment): التغييرات التي تجتاز الاختبارات تُجهَّز تلقائياً للإصدار، أو تُطلق للمستخدمين دون خطوة يدوية.
ما الفرق بين التسليم المستمر والنشر المستمر؟
مع التسليم المستمر، يكون كل تغيير يجتاز خط الأتمتة جاهزاً للإطلاق، لكن شخصاً ما يقرر متى يُطلق إلى الإنتاج. أما مع النشر المستمر، فكل تغيير ناجح يُطلق مباشرة دون أي موافقة بشرية.
هل أحتاج إلى CI/CD لتطبيق صغير بُني بالذكاء الاصطناعي؟
ليس في اليوم الأول. يمكن لتطبيق صغير بعدد قليل من المستخدمين أن يكتفي بالاختبار في معاينة (preview) والنشر يدوياً. يصبح CI/CD مفيداً عندما يعدّل عدة أشخاص الكود، أو عندما يعتمد عملاء حقيقيون على التطبيق، أو عندما تكسر أشياء كانت تعمل من قبل بشكل متكرر.
ما الأدوات المستخدمة في CI/CD؟
من الأدوات الشائعة GitHub Actions وGitLab CI/CD وCircleCI وJenkins، إضافة إلى خطوط النشر المدمجة في منصات الاستضافة. تؤدي جميعها المهمة الأساسية نفسها: تشغيل قائمة من الخطوات تلقائياً كلما تغيّر الكود.