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

في درسنا السابق، استكشفنا التكامل المستمر (CI)، حيث تُدمج تغييرات الكود وتُختبر بشكل متكرر. ولكن ماذا يحدث بعد دمج الكود واختباره؟

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

التسليم المستمر (CD) هو ممارسة في تطوير البرمجيات تُبنى فيها تغييرات الكود وتُختبر وتُجهّز تلقائيًا لإصدارها إلى بيئة الإنتاج.

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

تخيلوا آلةً تعمل بكفاءة لإعداد منتج، لكن شخصًا لا يزال يعطي الإشارة النهائية بالموافقة قبل مغادرته المصنع.

• تنفيذ Commit للكود: يرفع المطور الكود.
• مسار CI: يُبنى الكود، وتُجرى اختبارات الوحدة، ويُدمج.
• الاختبارات الآلية: تُجرى اختبارات إضافية (التكامل، ومن البداية إلى النهاية) تلقائيًا.
• إنشاء Artifact: تُنشأ حزمة قابلة للنشر (مثل صورة Docker).
• النشر في بيئة Staging: تُنشر الحزمة تلقائيًا في بيئة Staging لإجراء الفحوصات النهائية.
• الإصدار اليدوي: يوافق أحد أعضاء الفريق يدويًا على النشر إلى بيئة الإنتاج ويطلقه.

يحقق CD مزايا كبيرة لعملية التطوير:

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

يأخذ النشر المستمر (CDep) التسليم المستمر خطوةً أبعد. فهو يعني أن كل تغيير يجتاز جميع الاختبارات الآلية يُصدَر تلقائيًا إلى بيئة الإنتاج.

• لا توجد خطوة موافقة يدوية قبل النشر للمستخدمين.
• يتطلب ذلك مستوى عالٍ للغاية من الثقة في الاختبارات الآلية والمراقبة.

فكروا فيه كمصنع مستقل بالكامل تُبنى فيه المنتجات وتُختبر وتُشحن فورًا دون تدخل بشري.

• تنفيذ Commit للكود: يرفع المطور الكود.
• مسار CI: يُبنى الكود، وتُجرى اختبارات الوحدة، ويُدمج.
• الاختبارات الآلية: تُجرى جميع اختبارات التكامل والاختبارات من البداية إلى النهاية واختبارات الأداء تلقائيًا.
• إنشاء Artifact: تُنشأ حزمة قابلة للنشر.
• النشر في بيئة Staging: تُنشر الحزمة تلقائيًا في بيئة Staging.
• النشر الآلي في بيئة الإنتاج: إذا نجحت جميع الاختبارات، تُنشر الحزمة تلقائيًا في بيئة الإنتاج.

يحقق CDep أقصى سرعة للإصدارات وحلقات التغذية الراجعة:

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

يكمن الفرق الرئيسي بين التسليم المستمر والنشر المستمر في الجهة التي تتخذ قرار النشر إلى بيئة الإنتاج:

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

يعتمد الاختيار بين CD وCDep على مدى نضج فريقكم، وثقتكم في الأتمتة، وقدرتكم على تحمّل المخاطر.

• ابدؤوا بـ CD: إنها نقطة بداية أكثر أمانًا، وتساعد على بناء الثقة في مساركم.
• انتقلوا إلى CDep: لا تفعلوا ذلك إلا عندما تكون استراتيجيات الاختبار الآلي والمراقبة والتراجع لديكم قوية للغاية.
• راعوا السياق: غالبًا ما تفضّل القطاعات شديدة التنظيم (مثل قطاعات التمويل والرعاية الصحية) CD بسبب متطلبات الامتثال.

أي عبارة تصف على أفضل نحو الفرق الأساسي بين التسليم المستمر والنشر المستمر؟

لقد تعلّمتم الآن الفرق الأساسي بين التسليم المستمر والنشر المستمر!

• التسليم المستمر (CD): تكون البرمجيات جاهزة دائمًا للإصدار، لكن الإنسان يطلق النشر النهائي في بيئة الإنتاج.
• النشر المستمر (CDep): تُصدَر البرمجيات تلقائيًا إلى بيئة الإنتاج فور اجتيازها جميع الاختبارات الآلية.

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