كيفية التعامل مع الاختبارات المتقلبة في مجتمع المصادر المفتوحة

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



في هذا المنشور ، في الواقع ، سنخبرك بكيفية حل هذه المشكلة في Apache Ignite. نحن ديمتري بافلوف ، كبير مهندسي البرمجيات / مدير المجتمع في GridGain ، ونيكولاي كولاجين ، مهندس تكنولوجيا المعلومات في Sberbank Technologies.

كل ما هو مكتوب أدناه لا يمثل موقف أي شركة ، بما في ذلك سبيربنك. هذه القصة حصرية من أعضاء مجتمع Apache Ignite.

اباتشي اشعال والاختبارات

تبدأ قصة Apache Ignite في عام 2014 ، عندما تبرعت GridGain بالإصدار الأول من المنتج الداخلي لمؤسسة Apache Software Foundation. لقد مرت أكثر من 4 سنوات منذ ذلك الحين ، وخلال هذا الوقت اقترب عدد الاختبارات من علامة 60 ألف.

نستخدم JetBrains TeamCity كخادم تكامل مستمر - بفضل اللاعبين من JetBrains لدعمهم لحركة المصدر المفتوح. يتم توزيع جميع اختباراتنا بين الأجنحة ، حيث يقترب عددها للفرع الرئيسي من 140. وفي الأجنحة ، يتم تجميع الاختبارات وفقًا لمعايير معينة. يمكن أن يكون هذا بمثابة اختبار لوظائف Learning Machine [RunMl] أو ذاكرة التخزين المؤقت فقط [RunCache] أو [RunAll] بالكامل. في المستقبل ، سيعني تشغيل الاختبارات تمامًا [RunAll] - فحص كامل. يستغرق حوالي 55 ساعة من وقت الجهاز.

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

مشاكل مع قشاري

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

على من يقع اللوم؟

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

تقليديا ، يمكن تقسيم جميع أفراد المجتمع إلى مجموعتين:

• المتحمسون الذين يدخلون المجتمع بمحض إرادتهم والمساهمة في وقت فراغهم.
  
• المساهمون المتفرغون الذين يعملون لدى الشركات التي تستخدم بطريقة ما أو ترتبط مع هذا المنتج مفتوح المصدر.
  

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

الذي سوف إصلاح؟

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

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

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

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

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



حيث "جيد" هنا غير واضح. لكن على ما يبدو ، يعرف المؤلفون على الأقل أنه يجب إجراء الاختبارات.

كيف قاتلنا هذا

طريقة 1. اختبارات منفصلة

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

طريقة 2. الانفصال والإخطار

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



... 0 رد فعل الناس على هذه الرسائل. كل تجاهلها.

طريقة 3. الرصد اليومي

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

طريقة 4. أتمتة

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

ماذا يفعل الروبوت؟ يمكن دمج قدراتها في مجموعتين:

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

TeamCity بوت سير العمل

قبل Apache Ignite Teamcity Bot ، كانت عملية "المساهمة" في المجتمع على النحو التالي:

1. في JIRA ، يتم اختيار واحدة من التذاكر وثابتة ؛
   
2. يتم إنشاء طلب سحب ؛
   
3. يدير الاختبارات التي قد تتأثر بالتغييرات التي تم إجراؤها ؛
   
4. إذا نجحت الاختبارات ، فيمكن لمعاينة طلب السحب أن تتم معاينتها وتخفيفها.
   

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

يعاني أيضًا أفراد المجتمع الأكثر خبرة من التقلبات - يقضون وقتًا في تحليل الاختبارات التي وقعت عن طريق الصدفة ، وبالتالي يعيقون تطوير المنتج.

مخطط المساهمة مع TeamCity بوت

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

نظرة عامة على الميزة

قم بفحص المساهمة - قائمة بجميع مستشاري PRS غير المغلقة مع ملخص لكل معلومات: تاريخ آخر تحديث ورقم العلاقات العامة والاسم والمؤلف والتذكرة في JIRA .


لكل طلب سحب ، تتوفر علامة تبويب تحتوي على معلومات أكثر تفصيلاً: اسم العلاقات العامة الصحيح ، والذي بدونه لن يتمكن الروبوت من العثور على البطاقة المطلوبة في JIRA ؛ ما إذا كانت الاختبارات قد أجريت ؛ ما إذا كانت نتيجة الاختبار جاهزة ؛ ترك تعليق في جيرا.

تحليل نتائج الاختبار:




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



دعنا نعود إلى تقرير الروبوت. ينقسم هذا التقرير بصريًا إلى جدولين: حاصرات محتملة وكل الأعطال. تشمل حاصرات الاختبارات ما يلي:

• لديك معدل فشل في ماجستير أقل من 4 ٪ (أقل من 4 يبدأ من 100 كانت ناجحة) ؛
  
• ليست قشاري وفقًا لتصنيف TeamCity ؛
  
• سقط بسبب مهلة ، نفاد الذاكرة ، رمز الخروج ، فشل JVM.
  

على سبيل المثال ، في لقطة الشاشة أعلاه ، يشار إلى جناحين على أنهما مانعان محتملان - في الأول ، سقط الاختبار ، وفي الثانية ، انتهت مهلة.



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

تحليل نتائج الاختبار



على سبيل المثال ، نقوم بتحليل نتائج اجتياز الاختبارات في لقطة الشاشة أعلاه. وفقًا لإصدار bot ، يمكن أن يكون هناك عطلان بسبب خلل - تم سردهما في جدول Possible Blockers. ولكن قد يكون اختبارات قشاري مع انخفاض معدل الفشل. لاستبعاد هذا الخيار ، ما عليك سوى النقر فوق الزر Re-run blockers blockers ، وستذهب هذه الأجنحة إلى الاختيار المزدوج. لتبسيط المهمة بشكل أكبر ، يمكنك النقر فوق "إعادة تشغيل أدوات الحظر" والتعليق على JIRA ، والحصول على تعليق (ومعه إشعار عبر البريد الإلكتروني) من الروبوت بعد اكتمال الفحص. ثم ادخل وانظر إذا كانت هناك مشكلة أم لا.

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


تقرير مثالي: لم يتم اكتشاف حاصرات


تأشيرة خضراء (تعليق) للبوت. لم يتم العثور على حاصرات.


تأشيرة حمراء - التدقيق المزدوج و / أو تحرير الأخطاء المطلوبة

يحدث أن بعض الأخطاء لا تزال تتسرب إلى "سيد". كما قلنا ، قبل ذلك قاتل من خلال الإخطارات الشخصية. أو شخص ما تأكد من أن لا شيء سقط. الآن نستخدم حلاً أبسط:



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

وبالتالي ، تمكنا من زيادة عدد الإصلاحات الساخنة وتقليل الوقت المستغرق لإصلاح المشكلة بشكل كبير.

رصد حالة المعالج
من وظائف الروبوت الأخرى مراقبة حالة المعالج بالإحصائيات الخاصة بأحدث عمليات الإطلاق.



اتجاهات ماجستير



تقارن صفحة الاتجاهات الرئيسية تحديدين "رئيسي" لفترات زمنية محددة. يعرض كل عنصر في الجدول الحد الأقصى والحد الأدنى للقيمة والوسيط.


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

يضم Apache Ignite Teamcity Bot الآن أكثر من 65 عضوًا مسجلاً. خلال كامل فترة استخدام الروبوت ، تلقت التأشيرات أكثر من 400 طلب سحب ، ويتم إصدار خمسة تأشيرات في المتوسط ​​يوميًا.

هيكل TeamCity بوت

تتم استضافة الروبوت على خادم منفصل ، يذهب إلى ignite.apache.org للبيانات ، ويبلغ الجميع على قائمة التطوير - هذه هي منصتنا الرئيسية لمطوري Ignite - ويكتب تأشيرات الدخول إلى التذاكر من خلال واجهة برمجة تطبيقات JIRA API.



يستخدم خادم Jetty و servlets Jersey وعددًا من الخدمات ذات المنطق التجاري المعقد للبوت نفسه ، بما في ذلك خدمات Teamcity و JIRA و GitHub التي تصل إلى خدمة Ignited Integration. علاوة على هذا التكامل النقي لطلبات HTTP. كتخزين - يتم تضمين المنتج الخاص بـ Apache Ignite في وضع "تكوين عقدة واحدة" مع الثبات النشط. بالإضافة إلى المزايا الواضحة لاستخدام Ignite كقاعدة بيانات ، فإنه يساعدنا أيضًا في العثور على مجالات مختلفة لتطبيق Ignite وفهم ما هو مناسب وما هو غير مناسب.

تم استلهام الإصدار الأول من تطبيق bot من خلال مقال واحد حول REST caching وكان مخبأ REST وخدمات GitHub و Teamcity. تم تحليل Teamcity xml و json التي تم إرجاعها من الخادم بواسطة Pure Java Objects ، والتي تم تخزينها مؤقتًا بعد ذلك. في البداية كان يعمل ، وبسرعة كبيرة. ولكن مع زيادة كمية البيانات ، بدأت النتائج في التدهور.

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

تطوير TeamCity بوت

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

يتم إجراء جميع تحديثات البيانات الرئيسية بشكل غير متزامن ، وإلا فإننا نخاطر في الحصول على UX غير صحيح بسبب الإرجاع البطيء لبيانات TeamCity.

بالنسبة للسلاسل التي نادراً ما تغير قيمها (على سبيل المثال ، أسماء الاختبارات) ، يتم إجراء تعيين بسيط في المعرف ، والذي يتم إنشاؤه بواسطة التسلسل الذري. فيما يلي مثال على هذا الإدخال:



يتوافق اسم الاختبار الطويل مع الرقم int ، والذي يتم تخزينه في جميع البنيات. هذا يوفر كمية هائلة من الموارد. في أعلى الطرق التي تُرجع هذا الخط ، يوجد اعتراض ذاكرة التخزين المؤقت في الذاكرة Guava. بفضل التعليق التوضيحي المؤقت ، حتى في الكومة لا نختار سطور بقراءتها من Ignite by id. وبطبيعة الحال ، نحصل دائمًا على نفس الخط ، وهو أمر جيد للأداء.

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

لماذا TeamCity بوت هو أفضل

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

إضافة لطيفة هي الرسالة التي يرسلها الروبوت على ورقة ديف عندما يكتشف مشكلة. في المجتمع مباشرة ، هناك فرصة لبدء مناقشة: "هيا بنا ، ربما ، الآن سننعكس؟". هذا يضيف الثقة للمراجعين.

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

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