لقد قمنا مرة واحدة بتثبيت نظام إدارة المستندات الإلكترونية للعميل. ثم إلى كائن آخر. و واحدة اخرى. والرابع والخامس. لقد ابتعدنا كثيرًا حتى وصلنا إلى 10 أشياء موزعة. تحولت بقوة ... خاصة عندما وصلنا إلى تسليم التغييرات. كجزء من التسليم إلى الدائرة الإنتاجية لـ 5 سيناريوهات لنظام الاختبار ، فقد استغرق الأمر 10 ساعات و 6-7 موظفين. أجبرتنا هذه التكاليف على إجراء عمليات التسليم بشكل غير منتظم قدر الإمكان. بعد ثلاث سنوات من التشغيل ، لم نتمكن من تحمل ذلك وقررنا إضفاء الإثارة على المشروع بقليل من DevOps.
تستغرق جميع الاختبارات الآن 3 ساعات ، ويشارك فيها 3 أشخاص: مهندس واثنان من المختبرين. من الواضح أن التحسينات قابلة للقياس الكمي وتؤدي إلى انخفاض في TTM المحبوب. في تجربتنا ، هناك عدد أكبر بكثير من العملاء الذين يمكنهم الاستفادة من DevOps أكثر من أولئك الذين يعرفون عنها. لذلك ، من أجل تقريب DevOps من الأشخاص ، قمنا بتطوير مُنشئ بسيط ، والذي سنناقشه بمزيد من التفاصيل في هذا المنشور.
الآن دعنا نتحدث بمزيد من التفصيل. في إحدى شركات الطاقة ، يتم نشر نظام إدارة الوثائق الفنية في 10 منشآت كبيرة. في المشاريع بهذا الحجم ، ليس من السهل السباحة بدون DevOps ، لأن نسبة كبيرة من العمل اليدوي يؤخر العمل بشكل كبير ويقلل أيضًا من الجودة - كل الأعمال اليدوية محفوفة بالأخطاء. من ناحية أخرى ، هناك مشاريع لا يوجد فيها سوى تثبيت واحد ، ولكن كل شيء يحتاج إلى العمل تلقائيًا ، باستمرار ودون فشل - على سبيل المثال ، نفس أنظمة إدارة المستندات في المؤسسات الكبيرة المتجانسة. وإلا ، فسيقوم شخص ما بإجراء الإعداد يدويًا ، وتجاهل إرشادات النشر - ونتيجة لذلك ، سيتم فقد الإعداد عند البيع وسينهار كل شيء.
عادةً ما نعمل مع العميل من خلال عقد ، وفي هذه الحالة تتباين اهتماماتنا قليلاً. ينظر العميل إلى المشروع بدقة في حدود الميزانية والاختصاصات. قد يكون من الصعب أن تشرح له فوائد ممارسات DevOps المختلفة غير المدرجة في المواصفات. وإذا كان مهتمًا بالإصدارات السريعة ذات القيمة التجارية المضافة ، في بناء خط أنابيب للأتمتة؟
للأسف ، في العمل بتكلفة معتمدة مسبقًا ، لا يمكن دائمًا العثور على هذه الفائدة. في ممارستنا ، كانت هناك حالة اضطررنا فيها إلى التقاط التطوير لمقاول عديم الضمير وقذر. كان الأمر فظيعًا: لا توجد أكواد مصدر محدثة ، قاعدة الكود لنفس النظام في التركيبات المختلفة مختلفة ، الوثائق كانت غائبة جزئيًا ، جزئيًا كانت ذات جودة رهيبة. بالطبع ، لم يكن العميل يتحكم في الكود المصدري والتجميع والإصدارات وما إلى ذلك.
حتى الآن ، لا يعرف الجميع شيئًا عن DevOps ، ولكن الأمر يستحق الحديث عن مزاياها ، وعن التوفير الحقيقي للموارد ، وتضيء أعين جميع العملاء. لذا فإن الطلبات التي تتضمن DevOps أصبحت أكثر فأكثر بمرور الوقت. هنا ، من أجل التحدث بسهولة بنفس اللغة مع العملاء ، نحتاج إلى الربط بسرعة بين مشكلات الأعمال وممارسات DevOps التي ستساعد في بناء مسار التطوير الصحيح.
لذلك ، لدينا مجموعة من المشكلات من ناحية ، وهناك معرفة وممارسات وأدوات DevOps من ناحية أخرى. لماذا لا تشارك تجربتك مع الجميع؟
قم بإنشاء مُنشئ DevOps
Agile لها بيانها الخاص. ITIL لها منهجيتها الخاصة. DevOps أقل حظًا - لم تحصل بعد على قوالب ومعايير. بالرغم من تحديد درجة نضج الشركات بناءً على تقييم أساليب تطويرها وتشغيلها.
لحسن الحظ ، شركة Gartner سيئة السمعة في عام 2014 وحللت ممارسات DevOps الرئيسية والعلاقات بينها. بناءً على ذلك ، قمت بإصدار رسم بياني:
أخذناها كأساس لدينا . يحتوي كل مجال من المجالات الأربعة على مجموعة من الأدوات - قمنا بتجميعها في قاعدة بيانات ، وحددنا أكثرها شيوعًا ، وحددنا نقاط التكامل وآليات التحسين المناسبة. توتال تحولت 36 ممارسة و 115 أداة، ربعها مفتوح المصدر أو برمجيات حرة. بعد ذلك ، سنتحدث عن ما فعلناه في كل مجال ، وعلى سبيل المثال ، كيف يتم تنفيذه في المشروع لإنشاء إدارة المستندات الفنية ، والتي بدأنا بها المنشور.
العمليات
في مشروع EDMS سيئ السمعة ، تم نشر نظام إدارة الوثائق الفنية وفقًا لنفس المخطط في كل موقع من المواقع العشرة. يتضمن التثبيت 10 خوادم: خادم قاعدة البيانات وخادم التطبيق وفهرسة النص الكامل وإدارة المحتوى. في التثبيت ، يعملون داخل عقدة واحدة ، ويقعون في مركز البيانات في المرافق. تختلف جميع الكائنات اختلافًا طفيفًا في البنية التحتية ، لكن هذا لا يتعارض مع التفاعل العالمي.
أولاً ، وفقًا لممارسات DevOps ، قمنا بأتمتة البنى التحتية محليًا ، ثم نقلنا التسليم إلى دائرة الاختبار ، ثم إلى إنتاج العميل. تم وضع كل عملية خطوة بخطوة. يتم إصلاح إعدادات البيئة في نظام أكواد المصدر ، مع الأخذ في الاعتبار مجموعة أدوات التوزيع التي تم تصميمها للتحديث التلقائي. في حالة حدوث تغييرات في التكوين ، يحتاج المهندسون فقط إلى إجراء التغييرات المناسبة على نظام التحكم في الإصدار - وبعد ذلك سيعمل التحديث التلقائي دون مشاكل.
هذا النهج يبسط بشكل كبير عملية الاختبار. في السابق ، كان هناك مختبرين في المشروع لم يفعلوا شيئًا سوى تحديث المدرجات يدويًا. الآن يأتون للتو ، ويرون أن كل شيء يعمل ويفعلون المزيد من الأشياء المفيدة. يتم اختبار كل تحديث تلقائيًا - من مستوى السطح إلى أتمتة سيناريو الأعمال. يتم نشر النتائج كتقارير منفصلة في TestRail.
Культура
من الأفضل شرح التجريب المستمر من خلال تصميم الاختبار. اختبار نظام غير موجود بعد هو عمل إبداعي. عند كتابة خطة اختبار ، يجب أن تفهم كيفية الاختبار بشكل صحيح ، والفروع التي يجب أن تمر بها. وأيضًا إيجاد توازن بين الوقت والميزانية لتحديد العدد الأمثل للمراجعات. من المهم اختيار الاختبارات اللازمة بالضبط ، والتفكير في كيفية تفاعل المستخدم مع النظام ، ومراعاة البيئة والعوامل الخارجية المحتملة. لا غنى عن التجريب المستمر.
الآن عن ثقافة التفاعل. في السابق ، كان هناك جانبان متعارضان - المهندسين والمطورين. قال المطورون: "نحن لا نهتم بكيفية تشغيله. أنتم مهندسون ، وأنتم ذكيون ، تأكدوا من تشغيلها دون إخفاقات.. أجاب المهندسون: "أنتم مطورو البرامج مهملون للغاية. لنكن أكثر حرصًا ، وسنقلل من إصداراتك. لأنه في كل مرة تضع فيها رمزًا مسربًا لنا ، وليس من الواضح كيف يجب أن نتفاعل ".. هذه مشكلة تتعلق بالتفاعل الثقافي ، والتي تم إنشاؤها بشكل مختلف من وجهة نظر DevOps. هنا لديك كل من المهندسين والمطورين كجزء من فريق واحد يركز على التغيير المستمر ، ولكن في نفس الوقت برنامج موثوق.
على مستوى فريق واحد ، يتم ضبط المتخصصين لمساعدة بعضهم البعض. كما كانت من قبل؟ على سبيل المثال ، تم إعداد بعض تعليمات النشر الكثيفة ، بطول 50 صفحة ، قرأها المهندس ولم يفهم شيئًا ، وشتم وطلب من المطور التعليق في الثالثة صباحًا. علق المطور وشتم أيضًا - في النهاية ، لم يكن أحد سعيدًا. بالإضافة إلى ذلك ، بالطبع ، كانت هناك بعض الأخطاء ، لأنه لا يمكنك تذكر كل شيء في التعليمات. والآن يقوم المهندس ، جنبًا إلى جنب مع المطور ، بكتابة برنامج نصي للنشر الآلي للبنية التحتية لبرامج التطبيقات. ويتحدثون مع بعضهم البعض بنفس اللغة تقريبًا.
الناس
يتم تحديد حجم الفريق من خلال حجم التحديث. يتم تعيين الفريق أثناء تشكيل التسليم ، ويشمل من يرغب من فريق المشروع العام. ثم يتم كتابة خطة تحديث مع المسؤولين عن كل مرحلة ، حيث يقوم الفريق بتقديم التقارير فور اكتمالها. جميع أعضاء الفريق قابلة للتبادل. كجزء من الفريق ، لدينا أيضًا مطور على شبكة أمان ، لكنه لا يضطر أبدًا إلى الاتصال.
تكنولوجيا
هناك بعض النقاط التي تم تسليط الضوء عليها في مخطط التكنولوجيا ، ولكن تحتها هناك مجموعة من التقنيات - يمكنك نشر كتاب كامل مع أوصافها. لذلك سوف نسلط الضوء على الأكثر إثارة للاهتمام.
البنية التحتية كرمز
الآن ، على الأرجح ، لن تفاجئ أي شخص بهذا المفهوم ، لكن الأوصاف السابقة للبنى التحتية تركت الكثير مما هو مرغوب فيه. ، كانت بيئات الاختبار فريدة من نوعها ، فقد تم إعدادها والاعتزاز بها ، وتم تفجير جزيئات الغبار عنها.
الآن لا أحد يخاف من التجربة. هناك صور أساسية للأجهزة الافتراضية ، وهناك سيناريوهات جاهزة لنشر البيئات. يتم تخزين جميع القوالب والبرامج النصية في نظام التحكم في الإصدار ويتم تحديثها على الفور. في السابق ، عندما كان من الضروري تسليم بعض الحزم إلى الحامل ، ظهرت فجوة في التكوين. الآن تحتاج فقط إلى إضافة سطر في التعليمات البرمجية المصدر.
بالإضافة إلى سيناريوهات البنية التحتية وخطوط الأنابيب ، يتم أيضًا استخدام التوثيق كنهج رمز للتوثيق. بفضل هذا ، من السهل توصيل أشخاص جدد بالمشروع ، وتعريفهم بالنظام باستخدام الوظائف الموضحة ، على سبيل المثال ، في خطة الاختبار ، وكذلك إعادة استخدام حالات الاختبار.
العرض المستمر والمراقبة
حول DevOps ، تحدثنا عن كيفية اختيارنا للأدوات لتنفيذ عمليات التسليم والمراقبة المستمرة. غالبًا لا توجد حاجة لإعادة كتابة أي شيء - يكفي استخدام البرامج النصية المكتوبة مسبقًا ، وبناء التكامل بشكل صحيح بين المكونات وإنشاء وحدة تحكم إدارة مشتركة. ويمكن بدء جميع العمليات بزر واحد أو جدول زمني.
هناك مفاهيم مختلفة في اللغة الإنجليزية والتوصيل المستمر والنشر المستمر. يمكن ترجمة كليهما على أنهما "توريد مستمر" ، ولكن في الحقيقة هناك اختلاف بسيط بينهما. في مشروعنا الخاص بسير العمل الفني لشركة الطاقة الموزعة ، يتم استخدام التسليم - عندما يكون التثبيت للإنتاج تحت الأمر. في عملية التثبيت ، يحدث التثبيت تلقائيًا. أصبح التسليم المستمر في هذا المشروع بشكل عام الجزء المركزي من DevOps.
بشكل عام ، من خلال جمع معلمات معينة ، يمكنك أن تفهم بوضوح كيف تكون ممارسات DevOps مفيدة. وإحضاره إلى الإدارة التي تعشق الأرقام كثيرًا. العدد الإجمالي لعمليات الإطلاق ، ووقت تنفيذ خطوات البرنامج النصي ، ونسبة عمليات الإطلاق الناجحة - كل هذا يؤثر بشكل مباشر على الوقت المفضل لدى الجميع للتسويق ، أي الوقت من الالتزام بنظام التحكم في الإصدار إلى إصدار الإصدار في بيئة إنتاجية . مع تنفيذ الأدوات الصحيحة ، يتلقى المهندسون مؤشرات قيمة عن طريق البريد ، ويراها مدير المشروع على لوحة القيادة. حتى تتمكن من تقييم فوائد الأدوات الجديدة على الفور. ويمكنك تجربتها على بنيتك الأساسية باستخدام مُنشئ DevOps.
من يحتاج ?
دعونا لا نتظاهر: في البداية ، أصبحت مفيدة لنا. كما قلنا ، أنت بحاجة إلى التحدث بنفس اللغة مع العميل ، وبمساعدة مصمم DevOps ، يمكننا بسرعة رسم الأساس لمثل هذه المحادثة. سيتمكن محترفو الأعمال من تقييم ما يحتاجون إليه وبالتالي تطويرهم بشكل أسرع. حاولنا أن نجعل المُنشئ مفصلاً قدر الإمكان ، وأضفنا مجموعة من الأوصاف بحيث يفهم أي مستخدم ما يختاره.
يسمح لك تنسيق المُنشئ بمراعاة التطورات المتاحة بالفعل في الشركة لعمليات البناء والأتمتة. ليست هناك حاجة لهدم كل شيء وإعادة البناء إذا كان بإمكانك فقط اختيار الحلول التي تتكامل جيدًا مع العمليات الحالية التي يمكنها ببساطة سد الثغرات.
ربما يكون تطويرك قد انتقل بالفعل إلى مستوى أعلى وستبدو أداتنا أيضًا "كابتن". لكننا نجدها مفيدة لأنفسنا ونأمل أن تكون مفيدة لبعض القراء. نذكر على المُنشئ - إذا كان هناك أي شيء ، تحصل على المخطط فورًا بعد إدخال البيانات الأولية. سنكون ممتنين لردود الفعل والإضافات.
المصدر: www.habr.com