تخيل وضعًا رائعًا - قرر مدير الشركة تنفيذ DevOps. نفسه ، بدون ضغط من التقنيين. بدون مثال مقنع للمنافسين. أدركت الإدارة نفسها أنه من المستحيل تحسين جودة المنتج والقدرة على التنبؤ والشفافية وقابلية تكرار العمليات التجارية في تطوير وتنفيذ البرامج دون أدوات DevOps.
قدم؟ هل نجحت؟ لقد نجحت في اختبار أغنى خيال!
في الواقع ، بالطبع ، الأمر ليس كذلك. في معظم الأحيان ، لا تصل الإدارة إلى عناصر تكنولوجيا المعلومات الخاصة بنا. لذلك ، عليك أن تقنع. لكن كيف؟
عندما يتم تقديم حجة لزيادة ثقافة الاتصال بين المبرمجين ومسؤولي النظام ، فمن السهل أن تواجه حجة مضادة: هل أنت غير متحضر الآن ، أم ماذا؟ أو قد يذكرونك بالتكاليف التي تكبدتها الشركة بالفعل قبل عام أو عامين عندما انتقلت معًا إلى Agile. هل هناك ميزة في تكنولوجيا المعلومات كل عام يمكنها تطوير العمليات بطريقة ثورية؟
أما بالنسبة لتحسين جودة المنتج ، فيمكنك أيضًا أن تتلعثم. لكن كن حذرا. منذ مهمة البرمجة دون أخطاء لم تلغ بعد. نعم ، لا توجد أخطاء بأي شكل من الأشكال ، ولكن هذا هو السبب في أن الشركة لديها "قسم كامل من المختبرين" ، أليس كذلك؟
إن القدرة على التنبؤ بالعمليات هي بشكل عام عامل ذاتي ، والذي يصعب تبريره وتجنب النكات حول وانغ ونوستراداموس.
علاوة على ذلك ، إذا كنا نتحدث عن مؤسسة نموذجية ، فعلى الأرجح في مثل هذه الشركة ، يوجد بالفعل فريق تكنولوجيا معلومات معروف. وهذا الفريق في الإيقاع المعتاد القديم (باستثناء Agile) يعمل معًا لسنوات عديدة ولا يكاد يحترق بالرغبة (مرة أخرى) في تغيير شيء ما. كل شيء يناسب الجميع ، باستثناء القيادة بالطبع. الذي يرى أنه في برنامجهم يتم بث أي أخطاء باستمرار ، يتم تغيير شروط إصدار الإصدارات الجديدة.
بالطبع ، يمكن افتراض خيار آخر عندما يأتي شخص إلى الشركة من ذوي الخبرة في DevOps ، ويمثل بوضوح ما هي المشكلة وكيف يجب حلها. ومن يستطيع نقل رأيه للقيادة. ومع ذلك ، دعونا لا نأمل في عم معجزة.
وكسر الكثير على هذا. يبدأون بالقول أنه لا أحد يدعمهم ، وأنه من المستحيل تنفيذ أي شيء في هذا المستنقع ، ثم يذهب ببساطة إلى شركة أخرى ، حيث تتكرر الدورة.
اتضح دائرة مفرغة؟ لا ، لقد توصلنا تدريجياً إلى استنتاج مفاده أنه مع العمل التجاري تحتاج إلى التحدث فقط بلغة يفهمها - بلغة المال. للقيام بذلك ، نحصل على الورقة الرابحة الرئيسية من الأرجل ذات الأكمام الواسعة - تقليل الوقت المستغرق في السوق. نحتاج أن نثبت أنه بفضل DevOps ، سيتم إصدار إصدارات جديدة من المنتج مثل الكعك الساخن. ودعنا نترك بقية الفوائد المذكورة أعلاه من تنفيذ DevOps للعرض النهائي ، والذي سننشئه للمدير ، عندما يعمل كل شيء. سيقول الكثير أن هذا واضح للغاية. لا!
نحتاج إلى شيء سيأخذنا الحد الأدنى من الوقت والموارد (بعد كل شيء ، لن يسمح أحد بشطب أشهر العمل من أجل تطبيق DevOps معين ولن يشتري لنا خوادم جديدة بشكل عاجل) ، ولكن في نفس الوقت سيعطي نتيجة ملموسة للغاية (سيقلل بالفعل من الوقت إلى -سوق).
تحتاج أولاً إلى العثور على عنق الزجاجة ، ولكنه دائمًا واحد (الخطوة الأولى في نظرية قيود Goldratt). بعد التنفيذ الناجح لـ Agile (وكل هذا لا معنى له إلا بعد تنفيذ Agile) ، من حيث تطوير البرمجيات ، لا يزال عليهم الاختبار يدويًا. يمكن أن يستغرق اختبار الانحدار من أسبوعين إلى ثلاثة أسابيع حتى مع وجود حوض سباحة حر. ومن طريقة "يحب" المختبرون لإجراء اختبار الانحدار ، أعرف كل شيء.
لذا ، قررنا أن الاختبار هو عنق الزجاجة. ثم تحتاج إلى البدء في التشغيل الآلي. سوف يلاحظ الكثير: قول أسهل من فعله. لقد تم بالفعل كتابة ملايين الأسطر من التعليمات البرمجية ، ومن الجيد إذا قام المبرمجون على الأقل بتغطية شيء ما باختبارات الوحدة. في الواقع ، كل شيء ليس مخيفًا كما يبدو. تُظهر التجربة أن 80٪ من النتيجة الناجحة في شكل انخفاض خطير في الوقت المستغرق للسوق يتم تحقيقها من خلال 20٪ من الجهود. هذه هي تكلفة اختبار الأتمتة في حالتنا.
طبقًا لقانون باريتو ، نعم.
والأهم من ذلك ، يمكنك البدء في اختبار الأتمتة قبل موافقة الإدارة على تخصيص الموارد لتنفيذ الأجزاء المتبقية من DevOps. مشروع تجريبي صغير يمكن القيام به بمفرده في غضون أسبوع إلى أسبوعين.
ولكن في الوقت نفسه ، يمنحنا مثل هذا الوضع فرصة للفوز بانتصار مذهل ، والأهم ، سريع. بعد ذلك ، بعد اتخاذ موقف إيجابي وبركة القيادة ، يمكنك بالفعل طلب المال والموارد.
بادئ ذي بدء ، بالتأكيد ، يستخدم المبرمجون بالفعل نوعًا من برامج الخادم للبنى اليومية. يمكن أن يكون TeamCity ، أو Bamboo ، أو Jenkins ، - لا يهم. الشيء الرئيسي هو أن هناك بالفعل جزء من الأتمتة ويجب استخدامه ، وإذا لم يكن كذلك ، فمن السهل نشره في يوم واحد.
تحتاج أولاً إلى أتمتة اختبارات الدخان. ولكن كيف نفهم ما أتمتة؟ نعم ، ما عليك سوى إلقاء نظرة على ما كسرته بانتظام عندما تنشر التغييرات على مدى الأشهر الستة الماضية.
بعد ذلك ، تحتاج إلى إنشاء العديد من الاختبارات للتحقق من تشغيل العمليات التجارية الرئيسية. كيفية التعرف عليهم؟ لسؤال المحللين / المديرين / ممثلي الأعمال عن نوع الانهيار الذي يندفع به المدير الغاضب إلى مكتب المبرمج ويضع المهام بصوت مرتفع.
أسبوع ، حسنًا ، بحد أقصى اثنان لإنشاء مثل هذه الاختبارات. والنتيجة هي ردود فعل سريعة للغاية للأخطاء العالمية.
وبينما يكون المشروع دليلاً على وضع المفهوم ، لا تحتاج إلى إعداد نفس النشر التلقائي للخادم للاختبار والأقواس الأخرى ، ولكن القيام بكل شيء يدويًا. يمكن أن يتم هذا الجمال بسرور مع المسؤولين.
ليس من الصعب تخمين ما سيؤدي إليه هذا. سيرى المطورون على الفور (ويصححون) أخطائهم. سيتم تجنيب المختبرين روتين إجراء اختبارات طويلة ومملة للانحدار. سيكون أمامهم بضعة أيام لاختبار فقط تلك الأجزاء من التعليمات البرمجية التي كانت عرضة للتحرير. نعم بالضبط. وإذا لم يكن الأمر كذلك ، فارجع إلى البداية وتحدث مرة أخرى مع المحللين / المديرين / ممثلي الأعمال حول العمليات التجارية الهامة.
اختناق بسبب القضاء على الفرامل الرئيسية. الآن كل ما تبقى هو إصدار بعض الإصدارات الجديدة في بيئة إنتاجية ، وإزالة إحصائيات "كان / كان" والذهاب مع هذه الأرقام إلى الإدارة. ربح!
بعد هذا الانتصار المقنع ، يمكنك بالفعل التحدث عن أتمتة نشر المدرجات (على الأقل للاختبار). بعد ذلك ، اطلب أموالًا للرصد ومسرات DevOps الأخرى. يجب أن نتذكر أن مكونات النظام المتبقية لن يكون لها تأثير رائع على الأعمال.
مثال الاستوديو
في نهاية المنشور ، أعتقد أنه سيكون من المناسب إعطاء مثال على مشروع مكتمل بنجاح لتطبيق DevOps ، والذي تم تنفيذه من قبل شركتنا.
يمتلك بائع تجزئة كبير حوالي 20٪ من الأعمال في متجر عبر الإنترنت. في الوقت نفسه ، من الضروري الرد بسرعة كبيرة على حالة السوق وإجراء التغييرات اللازمة على البرنامج. وغالبا. وجودة عالية. يمكن لأي تأثير على الموقع أن يؤثر على التحويل ، ويتم التعبير عن المخاطر بأموال حقيقية.
لتقليل وقت تحديث الجودة وتحسينها ، تم إنشاء منصة اختبار آلي متخصصة يتم فيها أتمتة المهام الروتينية لاختبار التغييرات وتراجع موقع الويب. بالإضافة إلى ذلك ، تم بناء عملية تفاعل مجموعة الاختبار الآلي مع فرق التطوير. هذا سمح للمطورين بتحديد وتصحيح العيوب على الفور في النظام المحدث ، دون انتظار اختبار القبول النهائي.
وجد ممثلو بائع التجزئة التجربة ناجحة وقرروا تطبيقها على منتجات برمجية أخرى.
ومثال صغير آخر ، ولكن من ممارسة شركة تأمين كبيرة. قبل إدخال التشغيل الآلي للاختبار ، تم إصدار الإصدارات كل ستة أشهر. ليس لأن الشركة تطلبت ذلك كثيرًا - لكنها لم تعمل كثيرًا. وكان العميل يريد فقط. لذلك ، بعد شهرين من بدء تقديم أدوات الاختبار التلقائي ، تحول فريق تكنولوجيا المعلومات إلى تكرار إصدارات الإصدار لمدة أسبوعين.
مهم بما يكفي لبدء القيام بذلك ، أليس كذلك؟
سيرجي سترامنوف ، مهندس معماري سابق لمركز حلول برامج Jet Infosystems