زر واحد لاختبارها جميعًا. كيفية إبقاء جميع عمليات الدمج بعيدة عن الأنظار

مرحبا خابروفيتس! نحن - فلاديمير Myasnikov و فلاديسلاف إيغوروف - هي ممثلي مير Plat.Form اختبار التكامل فريق (NSPK JSC). سنخبرك اليوم عن أداة الأتمتة التي طورناها وطورناها ، والتي جعلت من الممكن تقليل الروتين في العمليات الداخلية للفريق.

مقدمة

يتضمن نظام الدفع Mir Plat.Form عدة عشرات من الأنظمة ، يتفاعل معظمها مع بعضها البعض باستخدام بروتوكولات وتنسيقات مختلفة. نحن ، فريق اختبار التكامل ، نتحقق من أن هذه التفاعلات تلبي المتطلبات المحددة.







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



تقول الرياضيات البسيطة ما يلي: عدد السلاسل المختبرة هو أنظمة N * عمليات تكامل M بينها * إصدارات K. حتى باستخدام مثال 13 نظامًا * 11 تكاملًا * 27 إصدارًا ، هناك ما يقرب من 3861 خيارًا ممكنًا لتوافق النظام. يبدو أن الجواب واضح - الاختبارات التلقائية؟ لكن المشكلة أكثر خطورة ، فالاختبارات التلقائية فقط لن تنقذك. نظرًا للعدد المتزايد من الأنظمة وعمليات تكاملها ، فضلاً عن التكرار المتغير للإصدارات ، فهناك دائمًا خطر اختبار سلسلة إصدارات النظام الخاطئة. لذلك ، هناك خطر فقدان عيب في التفاعل بين الأنظمة ، على سبيل المثال ، التأثير على التشغيل الصحيح لنظام الدفع Mir (PS).



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

• قدم قاعدة تحرير موحدة. بالنسبة لهذه المهمة ، كان تقويم الإصدار في Confluence كافيًا ، مما يشير إلى إصدارات الأنظمة المثبتة في PROD ؛
• نتتبع سلاسل التكامل وفقًا لتواريخ الإصدار. هنا أيضًا لم نعد اختراع العجلة ، سنحتاجها أكثر. لحل هذه المشكلة ، استخدمنا هياكل Epic في JIRA لاختبار تكامل الإصدارات. مثال على بنية الإصدار 1.111.0 من System3:

من ناحية ، ساعدت كل هذه الإجراءات في تحسين فهم الفريق لعمليات الدمج المختبرة وإصدارات النظام وتسلسل إصدارها في PROD. من ناحية أخرى ، لا يزال هناك احتمال لإجراء اختبار غير صحيح بسبب العامل البشري:

1. إذا تم نقل تاريخ إصدار أي نظام ، فسيحتاج عضو الفريق إلى تصحيح التقويم يدويًا والهيكل بأكمله في JIRA ، بما في ذلك المواعيد النهائية لإكمال المهام ، وربما إصدار الأنظمة المختبرة ؛
2. قبل اختبار التكامل ، تحتاج إلى التأكد من أن بيئة الاختبار تتكون من الإصدارات الصحيحة من الأنظمة. للقيام بذلك ، تحتاج إلى مراجعة مقاعد الاختبار يدويًا وتنفيذ بعض أوامر وحدة التحكم.

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



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



ما هي الخيارات التي تود تنفيذها في النظام قيد التطوير؟



1. إصدار تقويم واضح مع إمكانية عرض إصدارات جميع الأنظمة لتاريخ محدد.



2. بيئات المراقبة لاختبار التكامل:

• قائمة البيئات
• عرض مرئي لمقاعد وأنظمة الاختبار التي تشكل جزءًا من بيئة منفصلة ؛

• التحكم في إصدار الأنظمة المنتشرة على مناضد الاختبار.

3. العمل الآلي مع المهام في Jira:

• إنشاء هيكل إصدار ملحمي ؛
• إدارة دورة حياة مهام الاختبار ؛
• تحديث المهام في حالة حدوث تحول في تاريخ الإصدار ؛
• وضع التقارير الجذابة في مهام الاختبار.

4. العمل الآلي مع الفروع في Bitbucket ، أي إنشاء فروع التحرير في المشاريع:

• اختبارات التكامل
• التسخين التلقائي لبيئة التكامل.

5. واجهة مستخدم بديهية لتشغيل الاختبارات التلقائية وتحديث إصدارات النظام.

ما هو SMITH

نظرًا لأن النظام ليس معقدًا ، لم نكن أذكياء جدًا في التكنولوجيا. تمت كتابة الواجهة الخلفية بلغة Java باستخدام Spring Boot. الواجهة الأمامية هي رد فعل. لم تكن هناك متطلبات خاصة لقاعدة البيانات ، لذلك اخترنا MySql. نظرًا لأنه من المعتاد بالنسبة لنا العمل مع الحاويات ، فقد تم تغليف جميع المكونات المذكورة أعلاه في Docker ، بناءً على Docker Compose. يعمل SMITH بشكل سريع وموثوق مثل أنظمة Mir Plat.Form الأخرى.

دمج

• اتلاسيان جيرا. في jir ، يتم إنشاء مهام اختبار كل تكامل محدد وفتحها وإدخالها في العمل وإغلاقها ، وإذا نجحت جميع الاختبارات ، فسيتم إرفاق رابط لتقرير الجاذبية في التعليقات.
• Atlassian BitBucket. , , / . “” , .
• Jenkins. Jenkins, . , , glue Cucumber.
• . . ssh.

قبل أن تتمكن من الاحتفاظ بالتقويم ومراقبة حالة البيئات في SMIT ، تحتاج إلى إنشاء قائمة بالأنظمة قيد الاختبار والعلاقات بينها. يمكن إجراء جميع الإعدادات عبر واجهة الويب:







بعد إضافة النظام قيد الاختبار إلى قائمة SMIT:

1. سوف "يطرق" على كافة مضيفي الأنظمة المسماة SYS_CMD في قائمة البيئات ؛
2. يكتشف إصدار هذا النظام باستخدام الأمر المحدد في التكوين ؛
3. سيكتب إلى قاعدة البيانات الخاصة به الإصدار الحالي من هذا النظام والبيئة التي يظهر فيها.

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

إصدار التقويم

بعد أن يخبرنا مالكو الأنظمة أو قادة الفرق في فرق تطوير المنتج بتاريخ تثبيت الإصدار الجديد في PROD ، نسجل هذا الإصدار في التقويم. اتضح أن هذه هي الصورة:







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



توجد أيضًا في صفحة التقويم وظيفة لعرض إصدارات جميع الأنظمة لتاريخ محدد: من







الجدير بالذكر أنه عند تسجيل إصدار جديد في التقويم ، يقوم SMIT تلقائيًا بإنشاء بنية Epic في Jira وإصدار فروع في المشاريع في Bitbucket.

حالة البيئة

وظيفة أخرى مريحة للغاية لـ SMITH هي عرض الحالة الحالية لبيئة معينة. في هذه الصفحة ، يمكنك معرفة قائمة الأنظمة المضمنة في البيئة ومدى ملاءمة إصداراتها.







كما ترى في لقطة الشاشة ، عثر SMITH على إصدار System 4 قديم على host-4.nspk.ru ويعرض تحديثه. إذا ضغطت على الزر الأحمر بسهم أبيض ، فسيتصل SMITH بوظيفة Jenkins لنشر الإصدار الحالي من النظام في البيئة الحالية. من الممكن أيضًا تحديث جميع الأنظمة بعد الضغط على الزر المقابل.

بيئات اختبار التكامل

يجدر بنا أن نخبر قليلاً عن كيفية تعريفنا لبيئات الاختبار. بيئة واحدة هي مجموعة من الحوامل مع أنظمة Mir Plat.form المنتشرة والتكامل المخصص (نظام واحد في جناح واحد). في المجموع ، لدينا 70 منصة ، مقسمة إلى 12 بيئة.



في مشروع الاختبارات التلقائية للتكامل ، لدينا ملف تكوين يحدد فيه المختبرين بيئات الاختبار. تبدو بنية الملف كما يلي:

{  
   "properties":{  
      "comment":" system property   Environment.     property,   ,      System.getProperties()",
      "common.property":"some global property"
   },
   "environments":[  
      {  
         "comment":"  name,  Environment   common +  .  common1",
         "name":"env_1",
         "properties":{  
            "comment":" system property  Environment.    property.    ,      System.getProperties()",
            "env1.property":"some personal property"
         },
         "DB":{  
            "comment":" TestResource' DbTestResource.     id,       ",
            "url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
            "driver":"com.mysql.jdbc.Driver",
            "user":"fo",
            "password":"somepass"
         },
         "SYS_CMD":{  
            "comment":" TestResource'   RemoteExecCmd.    type = remote",
            "type":"remote",
            "host":"10.111.111.111",
            "username":"user",
            "password":"somepass"
         }
      }
   ]
}

بالإضافة إلى حقيقة أن هذا الملف ضروري حتى يعمل مشروع الاختبار التلقائي للتكامل ، فهو أيضًا ملف تكوين إضافي لـ SMIT. عندما تطلب تحديث المعلومات حول البيئات في SMIT ، يتم إرسال طلب HTTP إلى واجهة برمجة التطبيقات الخاصة بمجموعة bitbucket الخاصة بنا ، حيث نقوم بتخزين المشروع باستخدام الاختبارات التلقائية للتكامل. بهذه الطريقة ، يحصل SMITH على المحتويات الحالية لملف التكوين من الفرع الرئيسي.

اختبارات التشغيل

كان أحد أهداف إنشاء SMIT هو تبسيط إجراءات إطلاق اختبارات التكامل قدر الإمكان. لنفكر في ما حصلنا عليه في النهاية باستخدام مثال:







في صفحة اختبار النظام (في هذا المثال ، النظام 3) ، يمكنك تحديد قائمة الأنظمة التي تريد التحقق من التكامل معها. بعد تحديد عمليات الدمج المطلوبة والنقر على زر "بدء الاختبار" ، SMITH:



1. يشكل قائمة انتظار ويطلق وظائف Jenkins المقابلة بالتتابع ؛

2. يراقب تنفيذ العمل.

3- يغير وضع القضايا المقابلة في جيرة:

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

انتاج |

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



لنلخص ما تمكنا من تنفيذه:

1. تقويم إصدار مرئي مع إمكانية عرض إصدارات جميع الأنظمة في تاريخ محدد ؛
2. UI , , ;
3. ;
4. UI ;
5. Epic Task Jira, Allure ;
6. Bitbucket.

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



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