المقدمة

في بداية رحلتي، كنت مقتنعة إن الهدف من CI/CD هو إننا ننشر التطبيق في دقائق بدل ساعات.

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

أما الهدف الحقيقي، فكان شيء مختلف تمامًا.

تخيل فريق فيه 20 مطور.

كل يوم بيتم دمج عشرات التغييرات في المشروع.

ولو عملية النشر كلها يدوية...

هيحصل إيه؟

  • حد ينسى يشغل الاختبارات.
  • حد ينشر النسخة الغلط.
  • حد يستخدم إعدادات خاصة ببيئة مختلفة.
  • أو يكتشف المشكلة بعد ما المستخدمين يشتكوا.

المشكلة هنا مش إن الـ Deployment بياخد وقت...

المشكلة إن العملية نفسها غير قابلة للاعتماد عليها.

هنا ظهر مفهوم Continuous Integration (CI).

كل تغيير في الكود يمر بنفس الخطوات:

✅ Build

✅ Automated Tests

✅ Code Quality Checks

✅ Security Scanning (عند الحاجة)

وبالتالي، أي مشكلة تظهر في وقت مبكر، قبل ما توصل للإنتاج.

بعدها ييجي دور Continuous Delivery أو Continuous Deployment.

والفرق بينهم مهم:

  • Continuous Delivery: التطبيق يصبح جاهزًا للنشر في أي وقت، لكن قرار النشر قد يكون يدويًا.
  • Continuous Deployment: إذا اجتاز التغيير جميع المراحل المطلوبة، يتم نشره تلقائيًا دون تدخل بشري.

لاحظ إن الفكرة الأساسية مش:

"إزاي أنشر أسرع؟"

لكن:

"إزاي أخلي كل Deployment يتكرر بنفس الجودة، وبأقل احتمال للخطأ؟"

عشان كده، الشركات الكبيرة تقدر تنشر عشرات أو مئات المرات يوميًا...

لأنها بتثق في العملية، مش لأنها مستعجلة.

💡 الخلاصة

CI/CD مش مجرد Pipeline.

ولا مجرد Jenkins أو GitHub Actions.

هو أسلوب عمل بيهدف إلى:

  • تقليل الأخطاء البشرية.
  • اكتشاف المشاكل مبكرًا.
  • جعل النشر عملية متكررة ويمكن التنبؤ بها.
  • تقليل المخاطر المرتبطة بكل إصدار جديد.

ولما تقل المخاطر...

تزيد السرعة تلقائيًا.

🚀 في المقال القادم...

لو عندنا Monitoring وDashboards...

ليه ظهر مفهوم Observability؟ وهل هما نفس الحاجة؟