كيف شَكّل نموذج الشلال (Waterfall)، والنموذج المرن (Agile)، وغيرها من أُطر التطوير الشكل الحالي DevOps؟ إليك ما اكتشفناه.

إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟

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

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

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

والجدير بالذكر أن أغلب النماذج الحالية من نموذج التصميم الرشيق (Lean) ونموذج (Kanban) ونموذج التصميم المستمر (Continuous) ونموذج التصميم المرن (agile) تتتبع مبادئ وعمليات تعود إلى أوائل الأربعينات، لذا لا يمكن أن ندعي DevOps أنها فكرة جديدة كليًا.

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

اقتباس

"يبقى الأحمق أحمقًا حتى وإن كان معه أداة" - ماثيو ماثاي

نموذج الشلال التقليدي (Waterfall)

من وجهة نظرنا، تأتي أقدم الممارسات من نموذج الشلال، الذي قُدم لأول مرة من قبل الدكتور وينستون دبليو رويس في ورقة نشرت في السبعينيات.

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

نموذج التصميم الرشيق (Lean)

رغم أن التصميم الرشيق يعود إلى عام 1450 في مدينة البندقية، إلا أننا سنبدأ عندما قامت تويوتا بإنشاء نظام إنتاج تويوتا، الذي طوره المهندسون اليابانيون بين عامي 1948 و 1972. ونشرت تويوتا وصفًا رسميًا للنظام في عام 1992.

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

نموذج Kaizen

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

• التدفق (هو التوجه نحو تدفق المواد والمعلومات)
• العملية (وهي تعني تحسين وضعية عمل الشخص)

التسليم المستمر (Continuous Delivery)

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

نموذج التصميم المرن (Agile)

ظهر بيان تطوير البرمجيات المرنة في عام 2001، والذي كتبه مجموعة من الشبان الطموحين النهج المتبع في التطوير.

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

النموذج المرن المنضبط (Disciplined Agile Delivery)

ومنذ أن ظل البيان المرن ثابتًا لمدة 20 عامًا، بحث العديد من الممارسين للنموذج عن طرق لإضافة خيارات إضافية ومخصصة إلى النهج. بالإضافة إلى ذلك، يركز البيان المرن بشكل كبير على التطوير، لذا تكونت الحاجة الماسّة إلى الحلول بدلًا من الشيفرات البرمجية أو البرمجيات وخصيصًا في بيئة التطوير السريعة اليوم. شارك سكوت أمبلر وماركس بريز في تأليف عملية تسليم المرنة المنضبطة وإطار عمل مرن ومنضبط، استنادًا إلى خبرتهما في شركة Rational و IBM والمنظمات التي تحتاج فيها الفرق إلى مزيد من الخيارات المتاحة أو الشركات التي لم تكن ذات خبرة بما يكفي لتنفيذ المنهجية الرشيقة (lean)، أو حيث لا يتناسب دورة حياة البرمجية مع سياق النهج.

تأتي أهمية النموذج المرن النضبط أو ما يعرف DAD (اختصارًا للعبارة Disciplined agile delivery) و DA (اختصارًا للعبارة Disciplined agile) من أنه يسمح لنا باتخاذ قرارت حول العمليات بشكل مبسط من أجل تقديم حلول تدريجية ومتكررة. ويعتمد DAD على العديد من ممارسات تطوير البرمجيات المرنة (Agile)، بما في ذلك ممارسات Scrum، وممارسات نموذج الرشيق (Lean)، وغيرها. إن الاستخدام المكثف للنمذجة الرشيقة وإعادة تحليل، بما في ذلك تشجيع الأتمتة من خلال نموذج التطوير القائم على الاختبار TDD (اختصارًا للعبارة Test-driven Development)، والتصميم الرشيق مثل Kanban و XP و Scrum و Rup من خلال اختيار واحدة من خمس دورات حياة رشيقة، وإدخال مفاهيم هيكلية المالك (Architecture Owner)، يكتسب الممارسين لنموذج المرن مجموعة من الأفكار وطرق التفكير وعمليات وأدوات لتحقيق DevOps بنجاح.

نموذج DevOps

وعلى المدى الذي يمكننا أن نجمع فيه، ظهرت DevOps خلال سلسلة من DevOpsDays في بلجيكا في عام 2009، لتصبح الأساس للعديد من التحولات الرقمية. يعرّف مدير DevOps الأساسي في شركة مايكروسوفت Donovan Brown نموذج DevOps بأنه

اقتباس

إتحاد الأشخاص والعمليات والمنتجات لتمكين التسليم المستمر لتقديم القيمة Value (إن القيمة هي المنتج أو الخدمة، والتي يكون الزبون مستعدًا للدفع مقابلها) للعملاء.

والآن لنعود إلى سؤالنا الأصلي: إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟

إننا ننظر إلى التاريخ الذي يعود إلى 80 و48 و26 و17 عامًا، ولكن في وقتنا الحالي إن البيئة اليومية سريعة الإيقاع وغالبًا ما تكون مضطربة. بطبيعتنا نحن البشر نختبر ونجرب باستمرار ونتعلم ونتكيّف ونورّث نقاط القوة ونحل نقاط الضعف تيمّنًا بجيناتنا الوراثية.

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

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

نموذج eDevOps

في عام 2016، صاغ Brent Reed مصطلح eDevOps (لا توجد له مراجع في Google أو ويكيبيديا حتى هذه اللحظة)، وهو يُعرف بأنه "طريقة للعمل (Way of Work) التي تجلب التحسين المستمر في الشركة بسلاسة، من خلال الأشخاص والعمليات والأدوات.

وجد برانت أن النموذج المرن فشل في شركات تقنية المعلومات فالشركات التي اعتمدت تفكيرًا رشيقًا كانت لا تحقق قيمة (Value) للعملاء ولم تحقق أيضًا التركيز والسرعة التي توقعوها خبراء النموذج المرن الموثوق بهم في مجال تكنولوجيا المعلومات. وعندما شعر بالإحباط لرؤية "برج عاجي" تم فيه فصل فريق خدمات تقنية المعلومات المستقل عن فرق الدعم في مجال الهندسة والتطوير والعمليات ومكتب المساعدة، عندها طبق معرفته السابقة بنموذج التسليم الرشيق المنضبط (DAD)، وأضاف بعض الأهداف والتطبيقات العملية لمجموعة أدوات DAD، من ضمنها:

التركيز على الثقافة ودفعها من خلال عقلية التحسين المستمر (Kaizen)، والجمع بين الناس حتى عندما يكونون في غرفة واحدة. السرعة من خلال الأتمتة (TDD + إعادة تحليل كل شئ ممكن)، إزالة الهدر واعتماد نهج TOGAF، أو JBGE (وهو جيد إلى حدٍ ما) من أجل التوثيق تقديم القيمة (Value) من خلال النمذجة (نمذجة التصميم) و (shift left) لتمكين الكشف عن الأنماط المتضاربة أثناء المشاركة من خلال أنماط التعاون في مستودع رقمي أكثر تنوعا واستراتيجيا حديث

باستخدام خبرته مع AI في IBM، صمم برنت نموذج eDevOps الذي يقوم بشكل متزايد بأتمتة لوحات التحكم لأغراض القياس وصنع القرار بحيث يتم التحسين المستمر من خلال النشر المستمر (أتمتة العمليات من مرحلة التطوير إلى مرحلة الإنتاج) لجلب الإمكانيات الحقيقية لأي منظمة. إن برنامج التحول الفعال إلى eDevOps الذي يُبنى على التحول المنضبط إلى DevOps يُمكننا من القيام بما يلي:

• تحويل نظام الأعمال إلى Bizdevops) DevOps).
• تحويل نظام الأمن إلى SecDevOps) DevOps).
• تحويل نظام المعلومات إلى DataDevOps) DevOps).
• تقديم خدمات تقنية مترابطة بشكل خفيف والتي تجمع بين جميع أصحاب المصلحة.
• بناء حلول قابلة للاستخدام كل أسبوعين أو أسرع.
• جمع وقياس وتحليل وعرض وأتمتة الرؤية القابلة للتنفيذ من خلال عمليات DevOps من المفهوم من خلال الاستخدام المباشر للإنتاج.
• تحسين مستمر امتثالًا بنموذج Kaizen ونموذج الرشيق منضبط.

المرحلة التالية في تطوير DevOps

في النهاية هل تعدّ DevOps مجموعة من العبارات الطنانة والأفكار التقنية التي تُلقى على الشركات؟ سوف ندرك بكل تأكيد مع مرور الوقت كيف DevOps سيتقدم ويتطور. ومع ذلك، فإن حمض DevOps النووي يجب أن يستمر في النضج وأن يُنقح، ويجب أن يفهم المطورون أنه ليس الحل السحري ولا علاج لكل الأمراض والحلّ لكل المشاكل.

إذن ما هي العلاقة بين DevOps وبقية النماذج السابقة
DevOps != Agile != Lean Thinking != Waterfall
DevOps != Tools !=Technology
إن DevOps تحتوي على ممارسات من النموذج المرن (Agile) ونموذج التصميم الرشيق (Lean) ونموذج الشلال (Waterfall).

ترجمة -وبتصرف- للمقال Analyzing the DNA of DevOps لصاحبيه Willy-Peter Schaub و Brent Aaron Reed