هل تطبق الشركات منهجيات DevOps فعلاً؟ نظرة واقعية على الأنماط السائدة

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

كثيراً ما نسمع عن DevOps كحلّ سحري لكل مشاكل نشر البرمجيات، لكن الحقيقة؟ الممارسة الخاطئة لـ DevOps قد تكون أخطر من غيابها.

ضمن جلسة متميّزة من Mobile Dev Meetup، قادنا المهندس عبد الملك حناوي في رحلة نقدية كشف فيها الأنماط المضادة (Anti-Patterns) التي يقع فيها الكثير من الفرق دون وعي، بدءاً من العزلة بين الفرق، مروراً بالنشر اليدوي، ووصولاً إلى الكوارث التي تحدث في يوم النشر.

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

الفهرس:

  1. نظرة على دورة حياة تطوير البرمجيات SDLC
  2. العمليات التقليدية بين الفرق (Traditional Ops)
  3. الانتقال إلى المنهجيات الرشيقة (Agile)
  4. علاقة Agile بممارسات DevOps
  5. أنماط DevOps الصحيحة (DevOps Patterns) على مستوى الفريق 
  6. أنماط DevOps المغلوطة (DevOps Anti-Patterns) على مستوى الفريق
  7. أنماط النشر المغلوطة (Deployment Anti-Patterns)
  8. أنماط النشر الصحيحة (Deployment Patterns)

محاور الجلسة:

نظرة على دورة حياة تطوير البرمجيات SDLC:

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

يعاني هذا النموذج من مشاكل أبرزها: تأخير التسليمات، وانعدام الشفافية في المتابعة، وصعوبة التنبؤ بالمخاطر.

العمليات التقليدية بين الفرق (Traditional Ops):

تطرق المهندس عبد الملك إلى الطريقة القديمة في تقسيم المسؤوليات، حيث تعمل فرق التطوير، وفريق الـ QA، وفريق العمليات (Ops) بشكل منفصل، مما يؤدي إلى ضعف في التنسيق و بطء في الاستجابة للمشاكل.

الانتقال إلى المنهجيات الرشيقة (Agile):

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

علاقة Agile بممارسات DevOps:

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

أنماط DevOps الصحيحة (DevOps Patterns) على مستوى الفريق:

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

  • Type 1: تعاون مباشر بين فرق التطوير وفرق العمليات.
  • Type 2: توزيع كامل لمسؤوليات العمليات داخل الفريق.

أنماط DevOps المغلوطة (DevOps Anti-Patterns) على مستوى الفريق:

  • Anti-type A: وجود عزلة بين فرق التطوير والعمليات.
  • Anti-type B: وجود فريق DevOps ككيان معزول يعمل وحده.
  • Anti-type C: إلغاء دور فريق الـ Ops تماماً.

 إن جميع هذه الأنماط خاطئة و تساهم في تعقيد العمليات وتعطيل النشر السلس.

الأنماط المغلوطة في ال DevOps لا تكون فقط على مستوى تشكيل الفرق، بل أيضاً في ممارسات مرحلة نشر البرمجيات.

أنماط النشر المغلوطة (Deployment Anti-Patterns):

  • Manual Deployment (النشر اليدوي):

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

  • Big Bang Deployment (نشر دفعة كبيرة مرة واحدة):

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

أنماط النشر الصحيحة (Deployment Patterns):

  • Blue-Green Deployment:

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

  • Canary Deployment:

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

الختام:

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

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

نصيحة الجلسة الذهبية:
DevOps لا يعني وجود فريق DevOps، بل ثقافة تعاون وبناء مشترك بين الجميع.

روابط ذات صلة

ألبوم الصور


اكتشاف المزيد من Mobile Dev Meetup

اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.

اترك رد