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

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

نموذج عمل الAgile

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

 Rapid Application Development (RAD), Rational Unified Process (RUP), Scrum, and Extreme Programming (XP)

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

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

لم تنتهي القصة بعد، فبعد أن وضعت الأجايل المرونة في المقام الأول كأساس للتنفيذ ظهرت مشكلة جديدة بين المطورين و المشغلين (developers & operations) في الشركات التقنية. و لتضح الصورة دعني أوضح لك دور كل منهم، لعله من الواضح دور المطورين في المشاريع التقنية حيث يمثلون الجزء الرئيس في كتابة الكود و تنفيذ العمل. ألا أن هذا لا يمثل الجزء الوحيد في المنتج التقني بل إن المنتجات تحتاج لبنية تحتية من السيرفرات و قواعد البيانات و كيفية تواصل الأجزء المشغلة للمشروع بين بعضها البعض، بالإضافة لذلك متابعة الضغط المستمر على حاويات المنتج (السيرفرات) و التأكد أنها تعمل بطريقة مناسبة و أن الموارد الموجودة للسيرفر كافية لتستوعب عدد المستخدمين للمنتج التقني و أن المنتج تم رفعه و أصبح يعمل بشكل مناسب دون أخطاء. هذه الواجبات هي ما تمثل عمل المشغلين التقنيين و هو دور مهم كأهمية بناء المنتج و تطويره. إذن أين المشكلة؟ إن إطلاق المنتج و رفعه يؤثر في واقع الأمر على استقرار البنية التحتية و يمثل تحديا جديدا للمشغلين في الوصول إلى حالة الاستقرار للنظام. هذه المشكلة ليست جديدة في واقع الأمر لكنها لم تبرز سابقا فالwaterfall لم تكن تلجأ لجمع المشروع و اختباره و من ثم إطلاقه إلا مرة واحدة عند اكتماله، لكن المشكلة كانت عندما دعت الagile إلى مرونة أكبر تستدعي إطلاق المشروع بشكل متكرر بين حين و آخر، مما يعني التأثير على استقرار البنية التحتية بشكل مستمر و هو ما خلق فجوة بين المطورين الذين يعملون بشكل مستمر لإطلاق الميزات الجديدة و بين المشغلين الذين يسعون إلى استقرار النظام ككل حتى يعمل المنتج دون مشاكل.

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

ظهور الdevops

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

الContinuous Integration And Delivery

الفكرة الأساسية في التقريب بين المطورين و المشغلين هي ليست في تقسيم العمل لأجزاء صغيرة و حسب بل هو في بناء تلك الأجزاء الصغيرة ثم جمعها في كود واحد و اختبارها و رفعها و إطلاقها و من ثم العمل على أجزاء صغيرة أخرى بنفس الطريقة و بشكل متكرر و مستمر (continuous) . و هذا ما سيقود فريق العمل لتجنب جمع الأكواد الكبيرة مرة واحدة لتكوين كتلة كبيرة مليئة بالأخطاء و الثقيلة في رفعها للسيرفر و في توفير الموارد اللازمة في البنية التحتية. و هذه العملية المستمرة (continuous) في الجمع (integration) و الإطلاق و الرفع (deployment & delivery) هي تماما ما تنص عليه فكرة الCI/CD و التي هي Continuous Integration & Continuous Delivery.

قد لا يبدو تطبيق فكرة الCI/CD سهلا، و هو بالفعل ليس بتلك السهولة و لكن الوصول إليه و تطبيقه له نتائج إيجابية كبيرة في جعل العمل أكثر سلاسة و أكثر مرونة و قابلية في سرعة التنفيذ و الاختبار و الإطلاق و هو ما تدعو إليه الagile بشكل صريح. و لقيمته الكبيرة و أهميته فقد صدرت الكثير من الأدوات و التقنيات المخصصة في بناء بيئة الCI/CD بالإضافة لوجود أدوات ساعدت بشكل كبير في توفير نقطة الانطلاق في بناء بيئة الCI/CD و أقصد بكلامي هذا تحديدا الgit و الgithub. لكن هذه الأدوات و التقنيات تحتاج لخبرة و مهارة خاصة بها حتى يكون صاحبها قادرا على بناء بيئة توفر الCI/CD في الفريق التقني و تسهل من طريقة العمل و لعل هذا أحد الأسباب الرئيسية لتحول الdevops من مجرد طريقة و فلسفة في التقريب بين المطورين و المشغلين إلى مسمى وظيفي بحد ذاته تطلبه الشركات و تبحث بكثرة عن أصحابه في وقتنا الحالي.

هل انتهت القصة؟

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

و من يدري.. فالقصة لم تنتهي بعد.