كما كتبت ودافعت عن دبلوم في DEVOPS والممارسات الهندسية في 1C من الصفر

مقدمة

بدأ كل شيء منذ أكثر من عامين ، وانتقلت إلى السنة الرابعة من تخصص "معلوماتية الأعمال" في جامعة ولاية تومسك لأنظمة التحكم والإلكترونيات الراديوية (TUSUR). لم يكن هناك الكثير من الوقت المتبقي حتى نهاية الجامعة ، وكان احتمال كتابة دبلوم يلوح في الأفق أمام أعيننا. لم يتم النظر في فكرة شراء العمل النهائي. أردت حقًا أن أفعل شيئًا بنفسي. كان هناك الكثير من الخيارات لمواضيع مشاريع الدبلوم: مشاريع التكوين لأتمتة احتياجات الإنتاج للشركة ومشروع تنفيذ إدارة الوثائق بمفردها لـ 3 وحدات إقليمية وأكثر من 500 مستخدم نشط وإدخال EDI. باختصار ، كان هناك الكثير من الأشياء في رأسي ، ولكن لم يكن أي من هذه الملهمات وكان هذا هو الشيء الرئيسي.

في ذلك الوقت عملت في شركة ذات سمعة طيبة وفي مسائل العمل قابلت مبرمجًا رائعًا وعمومًا شخص جيد Andrei Shcheglov (مرحبًا Andrei!) وبطريقة ما = سألني خلال محادثة ما إذا سمعت أي شيء عن OneScript و لغة البرمجة غيركين. التي تلقيت إجابة لا ، لم أسمع. وبطبيعة الحال ، أدت المساء في google / Yandex وليلة بلا نوم إلى فكرة أنه هنا - عالم المجهول. لكن فكرة أن هذا يمكن أن يكون موضوع أطروحة لم تنشأ بعد. كانت الدائرة الروتينية للواجبات هي العمل المعتاد في مهمة 1C Configurator الحكيمة ، كما تفهم مع الاختبار اليدوي ولم تسمح لك بالانغماس تمامًا في نهج جديد في عالم 1C.

مفاهيم غير مألوفة

الصعوبة الأولى التي واجهتها كانت كمية لا تصدق من المصطلحات والأدوات المختلفة التي لم أسمع بها على الإطلاق - منذ ذلك الحين كنت "odnosnik نموذجي" (في هذه اللحظة يبدأ holivar ...) خاصة لا أعرف أي لغات برمجة أخرى ، و إلى جانب ذلك ، كانت منهجيات تقنية المعلومات الكبيرة غير مألوفة بالنسبة لي تمامًا ، كان علي أن أقفز من موضوع إلى آخر على الأقل لملء مسرداتي بطريقة أو بأخرى.

تقريبا في نفس اللحظة ، واجهت أنا (وزملائي) مشكلة محددة إلى حد ما. أخذوا وحدة البرامج من المقاول ، وفحصوا النسخ. يبدو أن كل شيء يعمل. ولكن بما أن هناك الكثير من العمل ، فقد وقعوا على قانون العمل المنجز وألقوه في الإنتاج. كان كل شيء جيدًا لمدة ستة أشهر ، حتى لم تتجاوز البيانات في هذا النظام الفرعي المسموح به. وبدأت تحدث أشياء غريبة للغاية. بدأ إجراء مستند من الوحدة لمدة 5-10 دقائق ، ظهرت مجموعة من الأخطاء ، حسنًا ، إلخ. كان عرض رمز البرنامج مرعبًا (لا تسأل لماذا لم يتم ذلك من قبل عند القبول ...). كان عدد الدورات المتداخلة خارج المعقول. كان الطلب الوحيد في الدورة الرابعة والطعن من خلال 4 نقاط تافهًا ، يتكرر على جميع المستندات السابقة لملء المستند الحالي ، ولصق نسخ 10 أضعاف من نفس الكتلة وأكثر من ذلك بكثير.

مثال تداخل:

ازدواجية الحقول في التخطيط:

علاوة على ذلك ، لملء هذه الحقول ، نسخة 14 نسخة.

بداية الدورة:

وحتى يصل متغير FF إلى 15:

حسنًا ، ومجموعة من الأعمال الفنية الفريدة الأخرى على قدم المساواة.

فجأة تذكرت أن هناك مكتبة بسيطة لحساب OneScript لحساب "cyclomaticity" للوحدة (1) (تعقيد الوحدة أو الطريقة). وجدت ، محسوبة. حصلت على قيمة 163 وحدة ، بقيمة لا تزيد عن 10. ووصلت إلى استنتاج مفاده أن اختبار قبول رمز البرنامج يجب أن يكون إلزاميًا ويجب أن يكون تلقائيًا ومستمرًا. ثم علمت عن التفتيش المستمر - وكما اتضح في عام 2006 ، قامت شركة IBM (2) بنشر منشور حول هذا الموضوع.

المزيد. ربما واجه العديد من العاملين في الشركات الكبيرة مشكلة نشر نسخة من قاعدة العمل على الجهاز المحلي للمطور. عندما تزن هذه القاعدة 5-10 غيغابايت - هذه ليست مشكلة ، وعندما تزن تيرابايت تقريبًا فقط في النسخ الاحتياطي ، فهذا أمر خطير بالفعل. ونتيجة لذلك ، استغرق الأمر 5-6 ساعات من وقت العمل لنشر نسخة حديثة. عندما سئمت من ذلك ، بدأت باستخدام أداة جيدة جدًا 1C-Deploy-and-CopyDB (بفضل أنطون!) ثم أدركت أن الأتمتة رائعة.

علاوة على ذلك ، كانت هناك مهام أخرى ، على سبيل المثال ، التحديث المنتظم للقاعدة الرئيسية والموزعة من التخزين في الليل ، واختبار النموذج ، واختبارات السيناريو ، وما إلى ذلك. تم تحقيق بعض هذا ، ولكن البعض الآخر لم يتحقق.

ولكن كل هذا كان ضروريا بالنسبة لي فقط. عند البحث عن أشخاص متشابهين التفكير في مدينته ، فشل عمليًا. إنهم ليسوا هناك. على الرغم من غريبة للغاية ، لأن المشاكل نموذجية. في تلك اللحظة كنت أعرف بالفعل أنني أريد أن أكتب أطروحته حول هذا الموضوع. ولكن لم أكن أعرف ماذا أكتب. لذلك ، كان عليّ الانضمام إلى المجتمع ليس للقراءة فحسب ، بل على الأقل كتابة الأسئلة وطرحها. كانت الأماكن الرئيسية حيث يمكنك طرح الأسئلة

مشاريع جيثب:

• https://github.com/silverbulleters/add

• https://github.com/oscript-library/opm

• https://github.com/EvilBeaver/OneScript

• https://github.com/silverbulleters/vanessa-runner/

منتدى XDD:

• قسم 1Script

• قسم الاختبار

• قسم أتمتة العمليات

حسنًا ووسيلة للاتصال السريع - مجموعات الملف الشخصي في Gitter

بدأ جمع المواد. كما هو مصير ، تمكنت من الاتصال ب Alexey Lustin alexey-lustin (Hi Alexey!) والتحدث عن فكرتي في الدبلوم في منتدى XDD. التي فوجئت بسماع التعليقات الموافقة وحتى دعوة للخضوع لممارسة ما قبل التخرج في Silver Bullet. لقد كان بالفعل انتصارا. لعدة ساعات ، توصلنا إلى موضوع ومحتوى الدبلوم. وضعنا المهام للعمل العملي. حصلت على رئيس مشروع الدبلومة من الشركة - Arthur Ayukhanov (Arthur hi!) كيف تمكن الشاب Padawan من الوصول إلى دورة الفيديو لمهندس الإصدار والقدرة على الحصول على Nikita Gryzlov (Hi Nikita!) بشكل غير محدود مع أسئلته ، وهو ممتن للغاية له.

باختصار:

موضوع الدبلوم هو "إدارة دورة حياة مؤتمتة لنظم المعلومات - هندسة النظم والبرمجيات للحلول على 1C: منصة المؤسسة في ظروف التحسين المستمر لجودة عملية الإنتاج".

الغرض من عمل التأهيل النهائي (WRC) هو تحديد العلاقة بين أدوات البرمجيات ووصف عملية الأعمال الخاصة بدائرة DevOps في منطقة 1C.

كان المبرر النظري للمشروع هو معيار التحسين المستمر لجودة الخدمة من ITIL 3.0 ، وكان الهدف العملي هو إنشاء حلقة تكامل مستمرة لحل التطبيق الجديد الذي طورناه - الحساب الشخصي للعميل. للقيام بذلك ، تم نشر خادم مصدر GitLab وحلقة بناء Jenkins. تم تشغيل الاختبارات على خادم مخصص (Windows Slave). تم إلغاء تحميل التكوين من مستودع 1C باستخدام مكتبة Gitsync ، الإصدار 3.0

(الموجود حاليًا في فرع التطوير) بالفعل مع إنجازات Alexei Khorev (Lech hello!) بتردد 30 دقيقة في فرع التطوير. كان سبب اختيار هذا الإصدار الخاص هو القدرة على الاتصال بالمستودع عبر بروتوكول tcp ، والذي ، للأسف ، لم يدعم GitSync 2.x النموذجي في ذلك الوقت. إذا تم تسجيل التغييرات في GitLab ، فسيبدأ تشغيل حلقة التكامل المستمر تلقائيًا.

نظرًا لأن ميزانية الحدث بأكمله كانت صفرًا ، وكانت القدرة على بناء تحكم كامل في جودة رمز البرنامج دون شراء وحدة لـ SonarQube أمرًا مستحيلًا ، فقد تم استخدام فحص بناء الجملة القياسي 1C كحل مبسط. على الرغم من أن التفريغ لمرة واحدة تم مع ذلك ، تم الحصول على النتائج وتحليلها. كما تم استخدام اختبارات إضافية للدورية ووجود رمز يمكن إعادة استخدامه.

في مرحلة اختبار الوظيفة ، تم استخدام إطارين Vanessa-Behavior و XUnitFor1C في نسختهما المدمجة المسماة Vanessa Automation Driven Development (Vanessa ADD). تم استخدام الأول لبدء اختبار السلوك المتوقع ، والثاني هو التحقق من فتح النماذج (اختبار الدخان). أدى تمرير حلقة التكامل المستمر إلى تقارير تم إنشاؤها تلقائيًا.

وفقًا لنتائج الاختبار ، اتخذ مهندس الإصدار قرارًا بدمج الفروع الرئيسية والمتطورة ، وأطلق المهمة الثالثة (يدويًا بالفعل) - نشر التغييرات على قاعدة البيانات المنتجة. قاعدة البيانات المنتجة غير متصلة بالمستودع ومغلقة تمامًا من التغييرات اليدوية. يتم التحديث فقط من خلال التسليم ، وفي الوضع التلقائي.

لوصف العملية التجارية للدائرة ، تم تشكيل رسم تخطيطي IDEF0 يتكون من 4 كتل متتالية تشكل مرور الدائرة. خطأ يحدث عند المرور عبر أي من المراحل يقطع عملية التجميع بإخطار لمهندس التحرير وينقل التحكم إلى الكتلة الخامسة من عملية التجميع ، حيث يتم إنشاء التقارير بتنسيق ALLURE و JUNIT وبالطبع cucumber.json.

وصف نموذج IDEF0

عملية "تفريغ كود المصدر في GIT"

بيانات الإدخال: - مستودع التكوين
الإخراج (الإخراج): - رمز المصدر
التحكم: تعليمات للعمل مع البرنامج النصي للتجميع
الآلية: 1C: Enterprise ، Gitsync .

من الشروط الأساسية لوجود الكفاف وجود ملفات المصدر. من إصدار النظام الأساسي 8.3.6 ، قدم 1C القدرة على تحميل أكواد مصدر التكوين إلى الملفات. وتجدر الإشارة إلى أن هذه العملية يمكن أن يكون لها عدة خيارات ، اعتمادًا على تفاصيل التطوير في قسم تكنولوجيا المعلومات. في الإصدار الحالي ، لتبسيط عملية انتقال الموظفين إلى المنهجية الجديدة ، تم إجراء التكامل مع عملية التطوير الحالية من خلال مستودع التكوين واستخدام مكون 1C.

في مرحلة عملية "تفريغ المصادر في GIT" ، سيتم إنشاء الملف وقاعدة معلومات الخدمة 1C ؛ تم توصيله بمخزن التكوين تحت حساب الخدمة ؛ يتم تلقي جميع التغييرات في الوقت الحالي (أو إلى آخر التزام في المستودع) ؛ تم تحميل رموز المصدر إلى دليل التجميع ؛ ملتزمة بنظام تخزين إصدار GIT ؛ يتم إرسال التغييرات إلى خادم مصدر GitLab

عملية "اختبار جودة الكود المصدري"

بيانات الإدخال: - رمز المصدر
الإخراج (الإخراج): - رمز المصدر
التحكم: تعليمات للعمل مع البرنامج النصي للتجميع
الآلية: 1C: Enterprise ، Deployka ، SonarQube ، Cyclo.os - (للأسف لا يوجد رابط)

في بداية هذه العملية ، يتم تخزين شفرة المصدر في مستودع GitLab. باستخدام البرنامج النصي للتحكم (التجميع) ، يتم تلقيه في دليل التجميع. عن طريق منصة 1C: Enterprise ، بناءً على رموز المصدر هذه ، يتم نشر قاعدة معلومات الخدمة. يتم إجراء تحليل للأخطاء باستخدام أدوات النظام الأساسي. إذا تم اكتشاف أخطاء رمز البرنامج أثناء التحليل والتي لا تسمح بتجميع التكوين ، فستتم مقاطعة العملية. الهدف من هذه الخطوة هو القضاء على الوقت المهدر لتحليل رمز برنامج تكوين غير معطل.

بعد التحقق من الأخطاء ، بدأ حساب التعقيد الحلقي لرمز البرنامج. تؤثر الزيادة في هذا المعامل بشكل كبير على تصحيح وتحليل رمز البرنامج. الحد الأقصى للقيمة المسموح بها هو 10. إذا تم تجاوزه ، يتم طرح استثناء ويتم إرجاع الرمز للمراجعة.

الخطوة الأخيرة في تحليل جودة رمز البرنامج هي التحقق من الامتثال لمعايير التطوير. لهذه الأغراض ، يستخدم المخطط المقترح خدمة SonarQube ووحدة دعم بناء الجملة 1C التي طورها من Silver Bullet. بناءً على نتائج التحليل ، يحسب النظام قيمة الدين التقني لكل موظف قام بنشر كود البرنامج.

عملية الاختبار الوظيفي

بيانات الإدخال: - رمز المصدر
الإخراج (الإخراج): - رمز المصدر
التحكم: تعليمات للعمل مع البرنامج النصي للتجميع
الآلية: 1C: Enterprise ، فانيسا - سلوك ، XunitFor1C .

أثناء عملية التطوير ، قد تحدث حالات قد تؤدي فيها الوظائف الجديدة إلى تعطيل تشغيل الأنظمة الفرعية الموجودة. يمكن أن يتجلى ذلك في تشكيل الاستثناءات ، واستنتاج النتيجة غير المتوقعة. لهذه الأغراض ، يتم اختبار السلوك المتوقع للنظام.

هناك عدة طرق تطوير واختبار قابلة للتطبيق في هذه الدائرة: TDD (التطوير القائم على الاختبار) و BDD (التطوير المدفوع بالسلوك)

في وقت كتابة WRC ، تم استخدام إطار Vanessa-bahavior لإجراء الاختبارات باستخدام منهجية BDD و XunitFor1C لـ TDD. يتم دمجها حاليًا تحت منتج Vanessa-ADD واحد. تم إيقاف دعم المطور للمنتجات القديمة. يتم إخراج نتائج الاختبار إلى ملفات تقرير Yandex Allure و Xunit.

عملية "تجميع التسليم"

بيانات الإدخال: - رمز المصدر
بيانات الإخراج: - تسليم التكوين
التحكم: تعليمات للعمل مع البرنامج النصي للتجميع
الآلية: 1C: Enterprise ، باكمان .

في هذه العملية ، يحدث التسليم النهائي لتسليم التكوين للنشر في النظام الهدف. كود المصدر الذي تم التحقق منه موجود في فرع تطوير مستودع كود مصدر GitLab. لتشكيل التسليم ، من الضروري أن تظهر التغييرات من فرع التطوير في الفرع الرئيسي . يمكن أن يحدث هذا الإجراء يدويًا وتلقائيًا ويتم تنظيمه حسب متطلبات قسم تكنولوجيا المعلومات باستخدام حلقة CI / CD. بعد دمج الفروع تبدأ عملية تجميع التسليم النهائي. للقيام بذلك ، مرة أخرى ، في دليل التجميع ، على أساس المصادر الموجودة ، يتم إنشاء قاعدة معلومات الخدمة ، ومن ثم ، باستخدام أدوات منصة 1C: Enterprise ، يتم إنشاء تسليم التكوين وأرشفته. تسليم التكوين هو المنتج النهائي لعملية التجميع ويتم تسليمه إلى العميل من خلال قنوات الاتصال القائمة أو يتم تثبيته مباشرة في نظام معلومات منتج.

نشر عملية النتائج

بيانات الإدخال: - نتائج التفريغ ، تقرير الملفات
بيانات الإخراج: - تقرير
التحكم: تعليمات للعمل مع البرنامج النصي للتجميع
الآلية: Yandex Allure ، Xunit .

عند تنفيذ خطوات العملية ، تقوم أدوات الاختبار بإنشاء ملفات تقرير بتنسيقات معينة كمنتج ثانوي. تتمثل مهمة هذه العملية في التجميع والتحويل والنشر لتسهيل تحليل البيانات. في حالة حدوث استثناء في مرحلة ما من التجميع والإعدادات اللازمة ، يجب على النظام إخطار مسؤول الحلقة تلقائيًا بالمشكلات. يتم تنفيذ هذه المرحلة في مرحلة ما بعد المعالجة لعملية التجميع ويجب تنفيذها بغض النظر عن نتائج العمليات السابقة.

للحصول على تعليقات ، بالإضافة إلى القائمة البريدية ، تم استخدام التكامل مع مدير شركة Slack ، حيث تم إرسال جميع رسائل المعلومات المتعلقة بحالة البناء ، وظهور الالتزامات الجديدة ، وتشكيل النسخ الاحتياطية ، بالإضافة إلى مراقبة أداء الخدمات المتعلقة بدائرة DevOps ومن 1C إلى كله.

وكانت نتائج مشروعي هي حماية المؤتمر العالمي للاتصالات الراديوية في نهاية مايو من هذا العام وكانت النتيجة "ممتازة". بالإضافة إلى ذلك ، تم تحديث المعلومات المنهجية حول تشكيل الكفاف.

استنتاجات عامة:

1. التأثير الاقتصادي ممكن فقط على المدى الطويل. من التجربة ، لوحظ أنه عند إطلاق مشروع تنفيذ الممارسات الهندسية ، يتم تسجيل انخفاض في إنتاجية التطوير بنسبة 20-30 ٪ من المستوى الحالي. هذه الفترة مؤقتة ، وكقاعدة ، يعود الأداء إلى قيمه الأولية بعد ثلاثة إلى أربعة أشهر من التشغيل. يرجع الانخفاض في الأداء في المقام الأول إلى حقيقة أن المطور يجب أن يعتاد على متطلبات التطوير الجديدة: كتابة النصوص والاختبارات وإنشاء وثائق فنية.
2. زاد استقرار نظام المعلومات الإنتاجية بشكل ملحوظ بسبب اختبار رمز البرنامج. يتم توفير التشغيل المضمون للأنظمة الفرعية الهامة من خلال تغطية اختبار السيناريو. ونتيجة لذلك ، تم تقليل مخاطر الشركة في منطقة حرجة - تم تقليل التفاعل التشغيلي مع العملاء.
3. إن استبعاد الإصلاحات الديناميكية على قاعدة معلومات منتجة جعل من الممكن التخطيط بشكل بناء بشكل أكبر ومنع رمز البرنامج من الالتفاف حول حلقة الاختبار.
4. تقليل تكاليف العمالة لخدمة قاعدة المعلومات بسبب أتمتة دائرة التجميع.
5. جعل استخدام التعليقات من خلال Slack من الممكن مراقبة وإصلاح مشاكل دورة حياة النظام عبر الإنترنت. وفقًا لمراجعات الفريق ، يعد استخدام برنامج المراسلة أكثر ملاءمة من البريد (على الرغم من وجوده أيضًا).
6. إن استخدام الفحص التلقائي المستمر للرموز (الفحص المستمر) للامتثال لمعايير التطوير (SonarQube) يجبر المطورين على زيادة كفاءتهم بشكل مستقل ، وإصلاح الدين التقني المحدد مباشرة أثناء تطوير وحدة البرامج هو أسرع بكثير ، حيث لا يتعين عليك قضاء الوقت في استعادة سياق المهمة.
7. يمكن أن يؤدي تمكين وظيفة التوثيق التلقائي وإنشاء إرشادات الفيديو إلى تقليل عدد طلبات المستخدم.
8. خلال فترة المشروع ، تم تشكيل عملية تجارية تصف دورة حياة تطوير واختبار حلول تطبيق 1C ، والتي أثرت بدورها على تشكيل مشروع لتنفيذ الممارسات الهندسية . , 1.

, . 90% .

, :

1. , " 1. - , , ( 5 ).
2. “ 1”. . ( , " ". ).
3. CICD 1 , 5.5.0 .

, , 1 , DevOps. , — DevOps 1 .

, DevOps 1. ?