نظرة عامة على مجال DevOps...

ربما كنت قد سمعت بمصطلح "DevOps"، فظننته الجزء الثاني من لعبة الفيديو الشهيرة (Psi-Ops)! في الواقع، أنت لم تُجانب الحقيقة بالكامل: ففي حين تحمل الشخصية الرئيسية في اللعبة مهارات مزدوجة (قتالية ونفسية)، يحمل العاملين في مجال DevOps مهارات مزدوجة.. لكن من نوعٍ آخر. 

ما هي؟ هذا ما سنتعرّف إليه عبر هذه التدوينة.

يُعتبر DevOps بمثابة زواج بين إدارتين متنافستين منذ الأزل: التطوير "Development" وإدارة العمليات/التنفيذ "Operations".
إدارتين متنافستين؟ نعم! فمنذ عُرفت الإدارة بشكلها الحديث، عانت فرق التطوير وفرق التنفيذ من ضعف التواصل والتعاون، لما؟ لأن لدى كل منها هدف يتعارض مع هدف الأخرى: ففي حين ترغب فرق إدارة العمليات برؤية المنتج مكتملاً بأعلى جودة وبأقل قدر ممكن من الموارد، تُصرّ فرق التطوير على التأكد من إنجاز العمل بالكامل وبجودة عالية، بغض النظر عن الموارد اللازمة لتحقيق النجاح.

تكمن المفارقة في كون هذا التعارض لا يؤدي لتخصيص الموارد بشكل مناسب ولا لإنجاز العمل بالجودة المطلوبة! وهنا يأتي دور DevOps.

تهدف DevOps لخلق بيئة تطوير تدعم التكامل المتواصل والتسليم المستمر. وذلك من خلال أربعة مبادئ رئيسية تقوم عليها DevOps:

• التكامل المتواصل (CI: Continuous integration): هو مصطلح خاص بهندسة البرمجيات يصف أسلوبًا في تطوير البرمجيات يتسم بتواصل عملية إعادة بناء تطبيق ما مصحوبة باختباره بصفة متكررة .
• التسليم المتواصل (CD: Continuous delivery): هو منهج يعتمده مهندسو البرمجيات في تطوير البرامج ضمن دورات قصيرة، ويهدف إلى تسريع بناء واختبار وإطلاق البرامج .
• الاختبار المتواصل (Continuous Testing).
• المراقبة المتواصلة (Continuous Monitoring).

وسنتعرف إلى كل منها بشكل مختصر أدناه:

التكامل المتواصل (CI: Continuous integration)

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

التسليم المتواصل (CD: Continuous delivery)

امتداد للعملية السابقة، ويعمل فيها الفريق على اختبار البرنامج بشكل مستمر مع كل ميزة جديدة تُضاف إليه.

الاختبار المتواصل (Continuous Testing)

هل يتطابق المنتج/البرنامج بصورته النهائية مع المتطلبات؟ هذا ما سيحرص عليه القائمين على الاختبار المستمر.

المراقبة المتواصلة (Continuous Monitoring)

وهي العملية المسؤولة عن مراقبة البرنامج أو الميزة الجديدة بحثًا عن الأخطاء والأمان والتوافق.

لنفهم أهمية DevOps لا بدّ أن نعود بالذاكرة إلى الأسلوب القديم في إدارة عملية التطوير والذي يُدعى (نموذج الشلال - Waterfall model).

ظهر نموذج الشلال لأول مرة عام 1970، ويعتمد على تقسيم عملية التطوير إلى مراحل منفصلة، بحيث لا تبدأ إحداها قبل الانتهاء من سابقتها. وتمثل "مخرجات" مرحلة ما "مدخلات" المرحلة اللاحقة لها.

وتنقسم تلك المراحل إلى:

1.     جمع وتحليل المتطلبات، ثم توثيقها ضمن ما يُدعى (وثيقة توصيف المتطلبات -Requirements Specification Document).

2.     تحديد بنية بيئة التطوير العامة، ثم بناءها وفقًا للمتطلبات السابقة.

3.     تفسيم البرنامج إلى وحدات صغيرة، وتطوير واختبار التوابع الوظيفية لكل وحدة (تُدعى هذه المرحلة: اختبار الوحدة - Unit Testing).

4.     بعد اختبار الوحدات السابقة، يقوم فريق التطوير بدمج كافة الوحدات، ثم اختبار البرنامج ككل للتأكد من خلوه من الأخطاء.

5.     إطلاق البرنامج في السوق.

6.     الصيانة وحل المشاكل -في حال وجودها باسستخدام برمجيات مُصممة لهذا الغرض وتُدعى (الرُقع- Patches).

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

وقد حملت تلك الطريقة اسم "آجايل Agile".

كن رشيقًا.. استخدم آجايل!

جاءت كلمة (آجايل-Agile) من كلمة Agility: والتي تعني الرشاقة وخفة الحركة.

هذا لأنها تعتمد التركيز على جانب معين داخل المنتج، يُنفّذ في وقت قصير، ثم يُعرض على العميل. وبذا سيتمكن العميل من رؤية (نسخة مُسبقة/أولية) من المنتج، وإن كانت هناك تعديلات فيمكن بسهولة إجراءها. وإلا انتقل فريق العمل لخاصية أخرى.. وهكذا دواليك حتى بناء المشروع بشكلٍ كامل.

ميزة هذه الطريقة الأساسية هي في أن المنتج الأولي -والذي سيدخل المرحلة التالية- هو منتج قابل للاستخدام والتطوير، إضافة لمطابقته الصورة المرسومة في ذهن العميل عن صورة المنتج النهائية.

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

إليك نظرة عامة وسريعة على الأدوار التي يمكنك توقع رؤيتها في DevOps:

• مهندس الـ DevOps أو المنصة.
• مهندس البناء.
• مهندس التوافقية.
• مدير الإطلاق.
• محلل البيانات.

مهندس الـ DevOps أو المنصة

هو الشخص الذي يفهم لغات الترميز المختلفة لدعم النظام الأساسي. الألقاب التي قد تراها هي (مهندس الـ DevOps أو مهندس المحطة) ، وهو من يؤسس لعملية الانتقال.

مهندس البناء

هو المسؤول عن بناء البرمجيات من التصور وحتى التسليم. البعض يسميه مهندس البناء Build Engineer / مصمم واجهات الاستخدام UX Designer / مدير التهيئة Configuration Manager. يحرص القائم بهذا العمل على تزامن وتطوير واختبار جميع البرامج والميزات.

مهندس التوافقية

يستخدم ( مهندس التوافقية Reliability Engineer) مزيجًا من تزامن التكويد والأتمتة لضمان تلبية منتج البرنامج للمتطلبات المحددة له.

مدير الإطلاق

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

محلل بيانات

يستخدم محلل البيانات البيانات العامة لاتخاذ قرارات بشأن رضا المستخدم والتي تؤثر على اتجاه المنظمة وجهود البرمجة. ويشترط لمحلل البيانات امتلاك مهارات التفكير النقدي ومشاركة المستخدم النهائي. البعض يُسميه أيضًا محلل ضمان الجودة QA analyst.