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