الإصدارات منخفضة المخاطر: 5 خطوات لبناء ممارسة DevOps الرائدة
لسنوات عديدة، كانت فرق البرمجيات غارقة في التأخير. وإليكم الأمر: لم تكن سرعة البرمجة للمطورين هي المشكلة الرئيسية.
كانت أطول فترات التوقف دائمًا هي الحصول على التعليمات البرمجية من خلال الموافقات والاختبار والتكامل.
ونتيجة لذلك، قامت الشركات بإصدار برامج ذات تحديثات ضخمة للميزات في أجزاء كبيرة على أساس دورة شهرية أو سنوية. كان هذا هو المعيار، حتى ظهور DevOps.
مع التغيير المستمر في المشهد التكنولوجي، انطلقت منهجيات DevOps، وبدافع الضرورة. تستخدم المؤسسات سريعة الحركة DevOps لإصدار الميزات وإصلاح الأخطاء بشكل أسرع.
تستفيد الشركات الناشئة من هذه التقنيات للذهاب إلى السوق بشكل أسرع واللحاق بـ “اللاعبين الكبار” في وقت أقل. وبهذه الطريقة، تعد DevOps بمثابة استراتيجية لتطوير الأعمال بقدر ما هي استراتيجية لتطوير البرمجيات.
يرى المستهلكون الفوائد المباشرة لـ DevOps ويتوقعون الآن تدفقًا لإصدارات الميزات الصغيرة بدلاً من الإصلاحات الكبيرة.
ولهذا السبب، تشعر الشركات بضغوط إضافية لمواكبة وتيرة الإصدار مع منافسيها. الهدف من DevOps ليس السرعة من أجل السرعة.
الهدف هو الإنتاج والقيمة قبل كل شيء. لتحقيق النجاح في DevOps، تحتاج إلى فحص دورة حياة البرنامج بأكملها والتفكير فيها كنظام، أو مصنع ينتج ميزات البرنامج.
تعامل مع مؤسستك كنظام
تخيل مصنع. بدلاً من إنتاج منتج مادي كما يفعل المصنع، فإنك تنتج ميزات. تأتي الأفكار وتخرج الميزات. تنتقل فكرتك إلى أسفل الحزام الناقل حيث يتم تجميعها واختبارها وتعبئتها وتسليمها إلى عميلك.
هدفك هو تحسين عملية الإنتاج بأكملها. ولكن كيف يمكنك استخدام DevOps (والمبادئ اللينة المتأصلة فيها) لتحسين مصنع برمجياتك؟ إليك الطريقة:
- تقليل حجم الدفعة الخاصة بك. أحد المبادئ الأساسية لمنهجية Lean هو القضاء على الهدر وتقليل العمل الجاري. بدلاً من مجموعة كبيرة من الميزات والتغييرات، يجب أن تكون إصداراتك عبارة عن ميزة أو تغيير واحد صغير. يجب أن يكون كل تحديث صغيرًا قدر الإمكان.
يتطلب هذا تغييرًا كبيرًا في الثقافة، وقد تواجه الكثير من المعارضة، حتى من المطورين لديك. لعقود من الزمن، كان “إصدار البرنامج” مرادفًا لمجموعة كبيرة من التغييرات الجذرية؛ كان الافتراض الأساسي هو أنه كلما تم إجراء المزيد من التحسينات والتغييرات خلال كل إصدار، كان الإصدار أفضل. لسوء الحظ، لا يزال هناك مطورين يشعرون أن إجراء عملية التكامل والنشر لإجراء تغيير صغير واحد هو مضيعة للوقت. قد يكون من الصعب إشراك الجميع في القيام بشيء ما بطريقة جديدة، لذا كن صبورًا. - إنشاء بيئات عالية الدقة. يعزز Lean بناء الجودة في العملية من خلال أتمتة وتوحيد المهام الشاقة والمتكررة. يجب أن يكون المطورون والمختبرون قادرين على إنشاء خوادم تم تكوينها تمامًا كما هي في الإنتاج، ويحتاجون إلى إنشائها من خلال عملية تلقائية دون الحصول على إذن من قسم تكنولوجيا المعلومات.
يتطلب هذا تحولًا في العقلية في قسم تكنولوجيا المعلومات/تكنولوجيا المعلومات لديك. لا تحب العديد من فرق IS/IT السماح للمطورين بتدوير أي خادم يريدونه. قد يؤدي إنشاء الآلات بإهمال إلى حدوث مشكلات تتعلق بتوفر الموارد والتكاليف. للتغلب على هذه العوائق، تحتاج إلى بناء الثقة بين أقسامك حتى ينجح هذا الأمر. إنشاء معايير وإجراءات تخفف من مخاطر قيام المطورين بإنشاء بيئاتهم الخاصة. ضع الضمانات في مكانها المناسب واجعلها مستقلة. - التكامل الآلي. يحظى التكامل المستمر (CI) باهتمام كبير في عالم DevOps لأنه يركز على التسليم السريع. يجب أن يكون المطورون قادرين على تنفيذ التعليمات البرمجية الخاصة بهم ونقلها وبنائها ودفعها إلى البيئة. ولكن حتى مع كل السرعة التي يمكن أن تنتجها، فإن CI لديها أيضًا إمكانات هائلة لتكون أكبر عنق الزجاجة.
من المحتمل ألا تأتي المقاومة التي قد تواجهها في أتمتة التكامل من البشر. تكمن أكبر التحديات في العقبات التقنية والبرامج القديمة التي لا ترغب في اللعب بشكل جيد مع الأساليب الأحدث مثل DevOps. قم بإنشاء خطة تكامل، وابدأ بدمج التطبيقات الصغيرة التي لها أهمية بالنسبة للشركة ولكنها تتطلب جهدًا أقل للتكامل. سيساعد هذا فريقك على معرفة المزيد حول عملية التكامل وإتقانها قبل البدء في المشاريع الكبيرة. - النشر الآلي. هناك طريقة أخرى للتسليم السريع وهي أتمتة النشر. يحتاج المطورون لديك إلى نشر تغييرات البرامج المعتمدة بسرعة ودون وقوع أي حادث. إن وجود أحجام دفعات أصغر سيساعد في ذلك، حيث أن حجم الدفعة الخاصة بك له علاقة مباشرة بمخاطر النشر. يجب أن يكون نشر تغيير البرنامج حدثًا غير ضروري.
ستكون أكبر عقبة أمام أتمتة النشر ضمن فرق البنية التحتية والأمان لديك. يواجه محترفو تكنولوجيا المعلومات ذوو الخبرة فكرة إجراء تغييرات كل يوم نظرًا لأن عمليات النشر كانت تمثل حدثًا كبيرًا (حتى في بعض الأحيان مليئة بالكعك والبيتزا والاحتفال الكبير). بالإضافة إلى ذلك، قد تحتاج الأتمتة بشكل فعال مع الحفاظ على مستوى عالٍ من الأمان إلى نهج DevSecOps، وهو أيضًا شيء جديد يجب مراعاته بالنسبة لفريق الأمان لديك. ولكن من خلال إجراء تغييرات صغيرة ومتكررة مع مرور الوقت، يصبح الأمر أقل رعبًا بكثير. - أتمتة أكبر قدر ممكن من الاختبار. الهدف هنا، والذي يرتكز أيضًا على فلسفة اللين، هو تقليل الهدر. يجب أن يقضي المختبرون وقتهم في بناء اختباراتهم وتحسينها، وليس تشغيلها. يجب أن تكون الاختبارات تلقائية، ويجب التعامل مع تكوين هذه الاختبارات على أنها كود المصدر. يجب أن يتم تشغيل اختباراتك بمجرد الموافقة على العناصر الجديدة ودفعها للاختبار. قد تظل بعض واجهات المستخدم أو المشاريع التي تتطلب مدخلات فريدة بحاجة إلى تلك اللمسة البشرية، ولكن يجب أن تكون الأغلبية بعيدة عن الأيدي.
ستواجه أقل قدر من الاحتكاك عند تنفيذ هذه الخطوة لأن معظم المختبرين يفضلون قضاء وقتهم في بناء الاختبارات وتحسينها بشكل إبداعي. امنحهم الوقت والاستقلالية للقيام بذلك.
تجنب صراعات اعتماد DevOps
فقط لأن DevOps هي طريقة أفضل للعمل لا يعني أن كل من يحاول ذلك ينفذ على مستوى عالٍ.
على سبيل المثال، تتبع العديد من الشركات نهج “الأداة أولاً” في تحولات DevOps. إنهم يشترون أدوات أتمتة جديدة فاخرة أو يحاولون ملاءمة الحاويات مع سير العمل الحالي لديهم.
لكن طرح التكنولوجيا الجديدة على عملية تطوير برمجيات سيئة لن يحل أي مشاكل. بدون تغيير جذري في العملية، لن تحصل على نتائج مختلفة.
الشركات التي تكافح من أجل اعتماد DevOps اليوم تواجه عوائق بسبب الاختناقات في عملياتها، وعادة ما تكون نفس الاختناقات التي كانت موجودة قبل بدء DevOps. يشملوا:
- في انتظار إنشاء بيئات الاختبار أو الاستضافة
- وقت الموافقة (الاختبار أو التوفير أو قواعد العمل)
- أوقات الانتظار أثناء إعادة العمل والانحدارات
البرمجيات وحدها لا تستطيع حل هذه المشاكل. وحتى بعد التأخير المتوقع في تقديم التكنولوجيا الجديدة والتدريب عليها ودمجها، فإن الشركات التي اتبعت نهج “الأداة أولاً” تشهد أداءً مماثلاً (أو حتى متدهوراً).
خلاصة القول: بغض النظر عن مدى مرونة وسرعة البنية التحتية لبرنامجك، إذا كان التزام التعليمات البرمجية ينتظر لمدة أسبوع لاختبار خط الأنابيب الخاص بك فهو خامل.
المصدر: pluralsight
قد يهمك:
