إذا كنت تدخل السيرفر بنفسك كل ما عدّلت على تطبيقك، وترفع الكود يدويًا، وتشغّل كم أمر، ثم تعيد تشغيل التطبيق وتدعي أن كل شيء يمشي بدون مشاكل، فهذا المقال لك. CI/CD هو الأسلوب الذي يجعل اختبار الكود ونشره يتمان بشكل آلي، فلا يعتمد النشر على ذاكرتك أو على أمر كتبته بسرعة.
الفيديو التالي يشرح الفكرة في دقائق قليلة، وتحته شرح نصي بالخطوات والنقاط المهمة حتى تقرأها أو ترجع لها لاحقًا.
لماذا النشر اليدوي مشكلة؟
المشكلة كما يوضحها الفيديو أن النشر بالطريقة اليدوية يعتمد عليك أنت. ممكن تنسى خطوة، أو تشغّل أمرًا خطأ، أو تنشر كودًا فيه مشكلة دون أن تنتبه. وكلما كبر التطبيق وزاد عدد من يعمل عليه، زادت احتمالات الخطأ.
تخيّل خمسة مطورين على نفس التطبيق: واحد يعدّل تسجيل الدخول، والثاني المدفوعات، والثالث قاعدة البيانات، وكل واحد يرفع تحديثاته باستمرار. السؤال الطبيعي: كيف نضمن أن تعديلًا واحدًا لم يكسر شيئًا آخر؟ هنا يأتي دور CI.
رحلة الكود من جهازك إلى المستخدم
يلخص الفيديو الرحلة كاملة في مسار واحد:
- الكود يبدأ من المطور.
- يروح إلى GitHub.
- يدخل مرحلة CI حيث يُختبر ويُبنى.
- ينتقل إلى Docker.
- ثم إلى بيئة Staging.
- ثم Production.
- وفي النهاية يُراقب باستخدام Monitoring.
أولًا: CI أو الدمج المستمر (01:06)
CI اختصار Continuous Integration. كل ما أحد عمل Push للكود، يبدأ الـ Pipeline تلقائيًا، فيثبّت الـ Dependencies، ويفحص الكود، ويشغّل الـ Tests، ويبني التطبيق.
إذا نجح كل شيء نكمل. وإذا ظهرت مشكلة يتوقف الـ Pipeline ويعطيك الخطأ قبل أن تكمل. الفائدة: بدل أن تكتشف المشكلة بعد النشر، تكتشفها مبكرًا. باختصار، CI يتأكد أن الكود سليم قبل دمجه.
ثانيًا: CD أو التسليم والنشر (01:39)
بعد أن نتأكد أن الكود سليم، نحتاج ننشره، وهنا دور CD:
- نبني نسخة من التطبيق، وممكن نضعها داخل Docker Image.
- نرسلها إلى بيئة اسمها Staging، وهي نسخة تجريبية من التطبيق نختبر فيها النسخة الجديدة قبل أن تصل للمستخدمين الحقيقيين.
- نتأكد في Staging أن تسجيل الدخول يعمل، وأن الـ API يعمل، وأن قاعدة البيانات سليمة، وأن فحوصات الصحة ناجحة.
- إذا كل شيء تمام، نكون جاهزين للإنتاج.
الفرق بين Continuous Delivery و Continuous Deployment (02:05)
هذه نقطة يخلط فيها كثيرون بين المصطلحين، والفيديو يفرّق بينهما:
- Continuous Delivery: النسخة تكون جاهزة للنشر، لكن لازم شخص يوافق ويضغط Deploy.
- Continuous Deployment: إذا نجحت كل الاختبارات، ينشر النظام النسخة الجديدة على Production تلقائيًا، بدون تدخل بشري.
وإذا جمعنا العملية كلها فهي: Code ثم Test ثم Build ثم Deploy ثم Monitor. الكود يتحرك عبر Pipeline واحدة من لحظة كتابته إلى أن يصل للمستخدم.
ماذا لو كانت النسخة الجديدة فيها مشكلة؟ (02:33)
هنا نحتاج طريقة آمنة للتعامل مع الأخطاء:
- Rollback: إذا ظهرت مشكلة في Production نرجع للنسخة السابقة المستقرة، وبكذا نقلل تأثير المشكلة على المستخدمين.
- النشر التدريجي: ما نرسل النسخة الجديدة لكل المستخدمين مرة واحدة. نبدأ بنسبة صغيرة مثل 5%، وإذا كل شيء طبيعي نرفعها إلى 25% ثم 50% ثم 100%. ولو ظهرت مشكلة نوقف النشر ونرجع للنسخة السابقة. هذا أحد الأساليب المستخدمة في النشر التدريجي، مثل Canary Release.
لا تنسَ المراقبة (03:07)
مجرد أن السيرفر اشتغل لا يعني أن التطبيق سليم. لازم تراقب الأخطاء والـ Latency والـ Requests وصحة التطبيق بشكل عام. النشر لا يعني أن المهمة انتهت، بل لازم تراقب التطبيق بعد النشر.
ماذا يعني هذا لك؟
- إذا كان نشر تطبيقك أو موقعك اليوم خطوات يدوية تتكرر كل مرة، فهذا أول مرشح للأتمتة.
- ابدأ بالأساس: Pipeline يشغّل الاختبارات ويبني المشروع عند كل Push.
- أضف بيئة Staging تجرّب فيها قبل أن تصل التحديثات للمستخدمين.
- جهّز خطة Rollback قبل أن تحتاجها، وفكّر في النشر التدريجي للتحديثات الكبيرة.
- لا تعتبر النشر نهاية العمل؛ فعّل المراقبة بعده.
الخلاصة
احفظها بهذه الطريقة: CI يسأل: هل الكود سليم؟ وCD يسأل: هل نقدر ننشره بأمان؟ وهذا هو CI/CD. بدل أن يكون نشر التطبيق مجموعة خطوات يدوية تتكرر كل مرة، يصير عندك Pipeline آلي يأخذ الكود من المطور، ويختبره، ويبنيه، وينشره، ويراقبه.
إذا كنت تبني موقعًا أو تطبيقًا لنشاطك وتحتاج من يرتّب لك هذه الآلية، يسعدنا نساعدك عبر خدمة تصميم وبرمجة المواقع، أو تواصل معنا وناقشنا مشروعك.