تعمل ممارسات DevOps. لقد كنا مقتنعين بهذا بأنفسنا عندما قمنا بتقليل وقت تثبيت الإصدار بمقدار 10 مرات. في نظام FIS Profile، الذي نستخدمه في VTB، يستغرق التثبيت الآن 90 دقائق بدلاً من 10. وقد انخفض وقت إنشاء الإصدار من أسبوعين إلى يومين. انخفض عدد عيوب التنفيذ المستمرة إلى الحد الأدنى تقريبًا. وللابتعاد عن "العمل اليدوي" والقضاء على الاعتماد على البائع، كان علينا العمل بالعكازات وإيجاد حلول غير متوقعة. يوجد أدناه قصة مفصلة حول كيفية بناء تطوير داخلي كامل.
مقدمة: DevOps هي فلسفة
على مدار العام الماضي، قمنا بالكثير من العمل لتنظيم التطوير الداخلي وتنفيذ ممارسات DevOps في VTB:
- قمنا ببناء عمليات تطوير داخلية لـ 12 نظامًا؛
- أطلقنا 15 خط أنابيب، تم إدخال أربعة منها إلى مرحلة الإنتاج؛
- 1445 سيناريو اختبار آلي؛
- لقد نجحنا في تنفيذ عدد من الإصدارات التي أعدتها فرق داخلية.
تبين أن أحد أصعب أنظمة التطوير الداخلي وتنفيذ ممارسات DevSecOps هو نظام ملف تعريف FIS - وهو معالج منتجات البيع بالتجزئة على نظام إدارة قواعد البيانات غير العلائقي. ومع ذلك، فقد تمكنا من بناء التطوير، وإطلاق المسار، وتثبيت حزم فردية غير إصدارية على المنتج، وتعلمنا كيفية تجميع الإصدارات. لم تكن المهمة سهلة، ولكنها مثيرة للاهتمام وبدون قيود واضحة في التنفيذ: هذا هو النظام - تحتاج إلى بناء تطوير داخلي. الشرط الوحيد هو استخدام القرص المضغوط قبل بيئة إنتاجية.
في البداية، بدت خوارزمية التنفيذ بسيطة وواضحة:
- نقوم بتطوير خبرات التطوير الأولية وتحقيق مستوى مقبول من الجودة من فريق الكود دون عيوب جسيمة؛
- نحن ندمج في العمليات الحالية قدر الإمكان؛
- لنقل التعليمات البرمجية بين المراحل الواضحة، نقوم بقطع خط الأنابيب ودفع أحد طرفيه إلى الاستمرار.
خلال هذا الوقت، يجب على فريق التطوير بالحجم المطلوب تطوير المهارات وزيادة حصة مساهمته في الإصدارات إلى مستوى مقبول. وهذا كل شيء، يمكننا اعتبار المهمة مكتملة.
يبدو أن هذا طريق موفر للطاقة تمامًا للوصول إلى النتيجة المطلوبة: هنا DevOps، وهنا مقاييس أداء الفريق، وهنا الخبرة المتراكمة... ولكن من الناحية العملية، تلقينا تأكيدًا آخر على أن DevOps لا تزال تدور حول الفلسفة ، وليس "مرتبطًا بعملية gitlab، وansible، وnexus، وفي أسفل القائمة."
بعد تحليل خطة العمل مرة أخرى، أدركنا أننا كنا نبني نوعًا من البائعين الخارجيين داخل أنفسنا. لذلك، تمت إضافة إعادة هندسة العمليات إلى الخوارزمية الموضحة أعلاه، بالإضافة إلى تطوير الخبرات على طول مسار التطوير بأكمله لتحقيق دور رائد في هذه العملية. ليس الخيار الأسهل، ولكن هذا هو طريق التطوير الصحيح الأيديولوجي.
أين تبدأ التنمية الداخلية؟
لم يكن النظام الأكثر ودية للعمل معه. من الناحية المعمارية، كان عبارة عن نظام إدارة قواعد بيانات كبير غير علائقي، ويتألف من العديد من الكائنات المنفصلة القابلة للتنفيذ (البرامج النصية، والإجراءات، والدفعات، وما إلى ذلك)، والتي تم استدعاؤها حسب الحاجة، وعملت على مبدأ الصندوق الأسود: يتلقى الطلب ويصدر استجابة. تشمل الصعوبات الأخرى الجديرة بالملاحظة ما يلي:
- اللغة الغريبة (النكاف)؛
- واجهة وحدة التحكم؛
- عدم التكامل مع أدوات وأطر التشغيل الآلي الشائعة؛
- حجم البيانات بعشرات التيرابايت؛
- تحميل أكثر من 2 مليون عملية في الساعة؛
- الأهمية - الأعمال الحرجة.
وفي الوقت نفسه، لم يكن هناك مستودع للكود المصدري من جانبنا. على الاطلاق. كانت هناك وثائق، ولكن جميع المعارف والكفاءات الأساسية كانت على جانب منظمة خارجية.
بدأنا في إتقان تطوير النظام من الصفر تقريبًا، مع مراعاة ميزاته وانخفاض توزيعه. البداية في أكتوبر 2018:
- دراسة التوثيق وأساسيات إنشاء الأكواد البرمجية؛
- لقد درسنا الدورة القصيرة حول التطوير التي تلقيناها من البائع؛
- إتقان مهارات التطوير الأولية؛
- قمنا بتجميع دليل تدريبي لأعضاء الفريق الجدد؛
- اتفقنا على ضم الفريق إلى الوضع "القتال".
- تم حل المشكلة المتعلقة بمراقبة جودة التعليمات البرمجية؛
- قمنا بتنظيم وقفة من أجل التنمية.
لقد أمضينا ثلاثة أشهر في تطوير الخبرة والانغماس في النظام، ومنذ بداية عام 2019، بدأ التطوير الداخلي حركته نحو مستقبل مشرق، أحيانًا بصعوبة، ولكن بثقة وهدف.
ترحيل المستودع والاختبارات التلقائية
مهمة DevOps الأولى هي المستودع. لقد اتفقنا سريعًا على توفير الوصول، ولكن كان من الضروري الانتقال من SVN الحالي بفرع رئيسي واحد إلى Git المستهدف مع الانتقال إلى نموذج من عدة فروع وتطوير Git Flow. لدينا أيضًا فريقان يتمتعان ببنية تحتية خاصة بهما، بالإضافة إلى جزء من فريق البائع في الخارج. كان علي أن أعيش مع اثنين من Gits وأضمن المزامنة. وفي مثل هذه الحالة، كان أهون الشرين.
تم تأجيل ترحيل المستودع مرارًا وتكرارًا، ولم يتم الانتهاء منه إلا في أبريل، بمساعدة زملاء من الخطوط الأمامية. مع Git Flow، قررنا إبقاء الأمور بسيطة في البداية واستقرينا على المخطط الكلاسيكي مع الإصلاح العاجل والتطوير والإصدار. قرروا التخلي عن السيد (المعروف أيضًا باسم النخز). سنشرح أدناه سبب كون هذا الخيار هو الأمثل بالنسبة لنا. تم استخدام مستودع خارجي خاص بالمورد، مشترك لفريقين، كعامل. تتم مزامنتها مع المستودع الداخلي وفقًا لجدول زمني. الآن مع Git وGitlab أصبح من الممكن أتمتة العمليات.
تم حل مشكلة الاختبارات التلقائية بسهولة مدهشة - لقد تم تزويدنا بإطار عمل جاهز. مع الأخذ في الاعتبار خصوصيات النظام، كان استدعاء عملية منفصلة جزءًا مفهومًا من عملية الأعمال وفي نفس الوقت كان بمثابة اختبار للوحدة. كل ما تبقى هو إعداد بيانات الاختبار وتعيين الترتيب المطلوب لاستدعاء البرامج النصية وتقييم النتائج. مع ملء قائمة السيناريوهات، التي تم تشكيلها على أساس إحصائيات التشغيل، وأهمية العمليات ومنهجية الانحدار الحالية، بدأت الاختبارات التلقائية في الظهور. الآن يمكننا البدء في بناء خط الأنابيب.
كيف كان: النموذج قبل الأتمتة
النموذج الحالي لعملية التنفيذ قصة منفصلة. تم نقل كل تعديل يدويًا كحزمة تثبيت تزايدية منفصلة. بعد ذلك جاء التسجيل اليدوي في Jira والتثبيت اليدوي على البيئات. بالنسبة للحزم الفردية، بدا كل شيء واضحًا، ولكن مع التحضير للإصدار، أصبحت الأمور أكثر تعقيدًا.
تم تنفيذ التجميع على مستوى عمليات التسليم الفردية، والتي كانت كائنات مستقلة. أي تغيير هو تسليم جديد. من بين أمور أخرى، تمت إضافة 60-70 إصدارًا تقنيًا إلى الحزم 10-15 من تكوين الإصدار الرئيسي - الإصدارات التي تم الحصول عليها عند إضافة أو استبعاد شيء ما من الإصدار وتعكس التغييرات في المبيعات خارج الإصدارات.
تداخلت الكائنات ضمن عمليات التسليم مع بعضها البعض، خاصة في التعليمات البرمجية القابلة للتنفيذ، والتي كانت أقل من النصف فريدة من نوعها. كان هناك العديد من التبعيات على الكود المثبت بالفعل وعلى الكود الذي تم التخطيط لتثبيته للتو.
للحصول على الإصدار المطلوب من الكود، كان من الضروري اتباع ترتيب التثبيت بدقة، حيث تمت إعادة كتابة الكائنات فعليًا عدة مرات، حوالي 10-12 مرة.
بعد تثبيت مجموعة من الحزم، اضطررت إلى اتباع التعليمات يدويًا لتهيئة الإعدادات. تم تجميع الإصدار وتثبيته بواسطة البائع. تم توضيح تكوين الإصدار تقريبًا قبل لحظة التنفيذ، مما يستلزم إنشاء حزم "فصل". ونتيجة لذلك، انتقل جزء كبير من الإمدادات من الإصدار إلى الإصدار مع ذيله الخاص من "الفصل".
من الواضح الآن أنه مع هذا النهج - تجميع أحجية الإصدار على مستوى الحزمة - لم يكن لفرع رئيسي واحد أي معنى عملي. استغرق التثبيت على الإنتاج من ساعة ونصف إلى ساعتين من العمل اليدوي. من الجيد أنه على الأقل على مستوى المثبت تم تحديد ترتيب معالجة الكائنات: تم إدخال الحقول والهياكل قبل البيانات والإجراءات الخاصة بها. ومع ذلك، هذا يعمل فقط ضمن حزمة منفصلة.
وكانت النتيجة المنطقية لهذا النهج هي عيوب التثبيت الإلزامية في شكل إصدارات ملتوية من الكائنات، والتعليمات غير الضرورية، والتعليمات المفقودة والتأثيرات المتبادلة غير المحسوبة للكائنات، والتي تم التخلص منها بشكل محموم بعد الإصدار.
التحديثات الأولى: الالتزام بالتجميع والتسليم
بدأت الأتمتة عن طريق إرسال التعليمات البرمجية عبر أنبوب على طول هذا المسار:
- استلام التسليم النهائي من المخزن؛
- تثبيته على بيئة مخصصة؛
- تشغيل الاختبارات التلقائية؛
- تقييم نتيجة التثبيت.
- اتصل بخط الأنابيب التالي على جانب أمر الاختبار.
يجب أن يسجل المسار التالي المهمة في Jira وينتظر توزيع الأوامر على حلقات الاختبار المحددة، والتي تعتمد على توقيت تنفيذ المهمة. الزناد - خطاب حول الاستعداد للتسليم إلى عنوان معين. كان هذا، بالطبع، عكازًا واضحًا، لكن كان علي أن أبدأ من مكان ما. في مايو 2019، بدأ نقل التعليمات البرمجية بإجراء فحوصات على بيئاتنا. لقد بدأت العملية، وكل ما تبقى هو وضعها في شكل لائق:
- يتم تنفيذ كل تعديل في فرع منفصل، يتوافق مع حزمة التثبيت ويتم دمجه في الفرع الرئيسي المستهدف؛
- مشغل إطلاق خط الأنابيب هو ظهور التزام جديد في الفرع الرئيسي من خلال طلب دمج، والذي يتم إغلاقه بواسطة المشرفين من الفريق الداخلي؛
- تتم مزامنة المستودعات مرة واحدة كل خمس دقائق؛
- يتم بدء تجميع حزمة التثبيت - باستخدام المجمّع المستلم من البائع.
بعد ذلك، كانت هناك بالفعل خطوات موجودة للتحقق من الكود ونقله، وإطلاق الأنبوب والتجميع من جانبنا.
تم إطلاق هذا الخيار في يوليو. أدت صعوبات التحول إلى بعض الاستياء بين البائع والخط الأمامي، ولكن خلال الشهر التالي تمكنا من إزالة جميع الجوانب الصعبة وإنشاء عملية بين الفرق. لدينا الآن التجميع بالالتزام والتسليم.
في أغسطس، تمكنا من إكمال التثبيت الأول لحزمة منفصلة على الإنتاج باستخدام خط الأنابيب الخاص بنا، ومنذ سبتمبر، دون استثناء، تم تنفيذ جميع عمليات تثبيت الحزم الفردية غير الصادرة من خلال أداة القرص المضغوط الخاصة بنا. بالإضافة إلى ذلك، تمكنا من تحقيق حصة من المهام الداخلية بنسبة 40% من تكوين الإصدار مع فريق أصغر من البائع - وهذا نجاح واضح. ظلت المهمة الأكثر خطورة هي تجميع الإصدار وتثبيته.
الحل النهائي: حزم التثبيت التراكمي
لقد فهمنا جيدًا أن كتابة تعليمات البائع كانت عبارة عن عملية أتمتة متوسطة المستوى، وكان علينا إعادة التفكير في العملية نفسها. كان الحل واضحًا - وهو جمع العرض التراكمي من فرع الإصدار بجميع كائنات الإصدارات المطلوبة.
لقد بدأنا بإثبات المفهوم: قمنا بتجميع حزمة الإصدار يدويًا وفقًا لمحتويات التنفيذ السابق وقمنا بتثبيتها على بيئاتنا. لقد نجح كل شيء، وتبين أن المفهوم قابل للتطبيق. بعد ذلك، قمنا بحل مشكلة برمجة إعدادات التهيئة وإدراجها في الالتزام. لقد قمنا بإعداد حزمة جديدة واختبرناها في بيئات الاختبار كجزء من تحديث الكفاف. كان التثبيت ناجحًا، على الرغم من مجموعة واسعة من التعليقات من فريق التنفيذ. لكن الشيء الرئيسي هو أننا حصلنا على الضوء الأخضر لبدء الإنتاج في إصدار نوفمبر مع تجميعنا.
ومع بقاء ما يزيد قليلاً عن شهر، تشير الإمدادات المنتقاة بوضوح إلى أن الوقت ينفد. لقد قرروا إجراء البناء من فرع الإصدار، ولكن لماذا يجب فصله؟ ليس لدينا ما يشبه Prod، والفروع الحالية ليست جيدة - فهناك الكثير من التعليمات البرمجية غير الضرورية. نحن بحاجة ماسة إلى خفض الإعجابات، وهذا يزيد عن ثلاثة آلاف التزام. التجميع يدويًا ليس خيارًا على الإطلاق. لقد قمنا برسم برنامج نصي يتم تشغيله من خلال سجل تثبيت المنتج ويجمع الالتزامات للفرع. في المرة الثالثة عملت بشكل صحيح، وبعد "الانتهاء من الملف"، أصبح الفرع جاهزا.
لقد كتبنا أداة البناء الخاصة بنا لحزمة التثبيت وانتهينا منها في غضون أسبوع. ثم كان علينا تعديل برنامج التثبيت من الوظيفة الأساسية للنظام، لأنه مفتوح المصدر. وبعد سلسلة من الفحوصات والتعديلات، اعتبرت النتيجة ناجحة. في غضون ذلك، تم تشكيل تكوين الإصدار، للتثبيت الصحيح الذي كان من الضروري محاذاة دائرة الاختبار مع الإنتاج، وتم كتابة برنامج نصي منفصل لهذا الغرض.
وبطبيعة الحال، كان هناك الكثير من التعليقات حول التثبيت الأول، ولكن بشكل عام نجح الكود. وبعد التثبيت الثالث، بدأ كل شيء يبدو جيدًا. تمت مراقبة التحكم في التركيب والتحكم في إصدار الكائنات بشكل منفصل في الوضع اليدوي، وهو ما كان مبررًا تمامًا في هذه المرحلة.
وكان التحدي الإضافي هو العدد الكبير من حالات عدم الإصدار التي يجب أخذها في الاعتبار. ولكن مع الفرع الشبيه بـ Prod وRebase، أصبحت المهمة شفافة.
لأول مرة وبسرعة وبدون أخطاء
لقد تعاملنا مع الإصدار بموقف متفائل وأكثر من عشرة عمليات تثبيت ناجحة على دوائر مختلفة. ولكن حرفيًا قبل يوم واحد من الموعد النهائي، اتضح أن البائع لم يكمل العمل لإعداد الإصدار للتثبيت بالطريقة المقبولة. إذا لم يعمل البناء الخاص بنا لسبب ما، فسيتم تعطيل الإصدار. علاوة على ذلك، من خلال جهودنا، وهو أمر غير سارة بشكل خاص. لم يكن لدينا وسيلة للتراجع. لذلك، فكرنا في الخيارات البديلة وأعدنا خطط العمل وبدأنا في التثبيت.
والمثير للدهشة أن الإصدار بأكمله، والذي يتكون من أكثر من 800 عنصر، بدأ بشكل صحيح، في المرة الأولى وفي 10 دقائق فقط. لقد أمضينا ساعة في التحقق من السجلات بحثًا عن الأخطاء، لكننا لم نجد أيًا منها.
ساد الصمت في محادثة الإصدار في اليوم التالي بأكمله: لم تكن هناك مشاكل في التنفيذ، أو إصدارات ملتوية أو تعليمات برمجية "غير مناسبة". لقد كان الأمر محرجًا إلى حد ما. في وقت لاحق، ظهرت بعض التعليقات، ولكن بالمقارنة مع الأنظمة الأخرى والخبرة السابقة، كان عددها وأولويتها أقل بشكل ملحوظ.
كان التأثير الإضافي من التأثير التراكمي هو زيادة جودة التجميع والاختبار. نظرًا لعمليات التثبيت المتعددة للإصدار الكامل، تم تحديد عيوب البناء وأخطاء النشر في الوقت المناسب. أتاح الاختبار في تكوينات الإصدار الكامل إمكانية تحديد العيوب في التأثير المتبادل للكائنات التي لم تظهر أثناء التثبيتات الإضافية. لقد كان نجاحًا بالتأكيد، خاصة بالنظر إلى مساهمتنا بنسبة 57% في الإصدار.
النتائج والاستنتاجات
وفي أقل من عام تمكنا من:
- بناء تنمية داخلية كاملة باستخدام نظام غريب؛
- القضاء على التبعية الحرجة للبائع؛
- إطلاق CI/CD لإرث غير ودي على الإطلاق؛
- رفع عمليات التنفيذ إلى مستوى تقني جديد؛
- تقليل وقت النشر بشكل كبير؛
- تقليل عدد أخطاء التنفيذ بشكل كبير؛
- أعلن بثقة أنك خبير تطوير رائد.
وبطبيعة الحال، فإن الكثير مما تم وصفه يبدو وكأنه حماقة صريحة، ولكن هذه هي ميزات النظام وقيود العملية الموجودة فيه. في الوقت الحالي، أثرت التغييرات على منتجات وخدمات IS Profile (الحسابات الرئيسية، والبطاقات البلاستيكية، وحسابات التوفير، والضمان، والقروض النقدية)، ولكن من المحتمل أن يتم تطبيق هذا النهج على أي IS تم تعيين مهمة تنفيذ ممارسات DevOps لها. يمكن تكرار النموذج التراكمي بأمان للتطبيقات اللاحقة (بما في ذلك التطبيقات التي لم يتم إصدارها) من العديد من عمليات التسليم.
المصدر: www.habr.com