في الأيام الخوالي ، كان لدينا عدد قليل من الخدمات ، وكان
نجاح تحديث أكثر من واحدة منها في الإنتاج في يوم واحد بمثابة
نجاح كبير. ثم تسارع العالم ، وأصبح النظام أكثر تعقيدًا ، وتحولنا إلى مؤسسة ذات بنية ميكروية للخدمات. الآن لدينا حوالي مائة خدمة ، ومع زيادة عددهم ، يزداد تواتر الإطلاقات أيضًا - هناك أكثر من 250 خدمة أسبوعيًا.
وإذا تم اختبار الميزات الجديدة داخل فرق المنتج ، فإن مهمة فريق اختبار التكامل هي التحقق من أن التغييرات المضمنة في الإصدار لا تنقطع عن وظائف المكون والنظام والميزات الأخرى.
أنا أعمل مهندس أتمتة اختبار في Yandex.Money.
في هذه المقالة ، سأتحدث عن تطور اختبار تكامل خدمات الويب ، وكذلك حول تكييف العملية لزيادة عدد مكونات النظام وزيادة عدد مرات تكرار الإصدارات.
حول التغييرات في دورة الإصدار وتطوير آلية الحساب تم وصفها بواسطة ops و dev في
إحدى المقالات السابقة . سوف أخبرك بتاريخ التغييرات في عمليات الاختبار أثناء هذا التحول.
الآن لدينا حوالي 30 فريق تطوير. يضم الفريق عادة مدير المنتج ، مدير المشروع ، مطوري واختبار الواجهة الأمامية والخلفية. يتم توحيدهم من خلال العمل على المهام لمنتج معين. بالنسبة للخدمة ، كقاعدة عامة ، يكون الفريق مسؤولًا ، والذي يقوم غالبًا بإجراء تغييرات عليه.
اختبار القبول من طرف إلى طرف
منذ وقت ليس ببعيد ، مع إطلاق كل مكون ، تم تشغيل اختبارات الوحدة والمكونات فقط ، وبعد ذلك تم تشغيل عدد قليل فقط من أهم البرامج النصية من البداية إلى النهاية على بيئة اختبار كاملة قبل وضع الخدمة في الإنتاج. جنبا إلى جنب مع الزيادة في عدد المكونات ، بدأ عدد الاتصالات بينهما ينمو بشكل كبير. في كثير من الأحيان - اتصالات غير تافهة تماما. أتذكر كيف أدى عدم توفر الخدمة لإصدار بيانات التسويق إلى كسر تسجيل المستخدم بالكامل (بالطبع ، لفترة قصيرة).
بدأت هذه الطريقة في التحقق من التغييرات تفشل مرارًا وتكرارًا - تتطلب تغطية جميع سيناريوهات العمل المهمة مع الاختبارات التلقائية وتشغيلها على بيئة اختبار كاملة مع إصدار مكون جاهز للإصدار.
حسنًا ، لقد ظهرت اختبارات تلقائية للسيناريوهات الهامة - ولكن كيف يتم تشغيلها؟ كانت هناك مهمة لدمجها في دورة الإصدار ، مما أدى إلى الحد الأدنى من موثوقيتها مع قطرات اختبار زائفة. من ناحية أخرى ، أردت تنفيذ مرحلة اختبار التكامل في أسرع وقت ممكن. لذلك كان هناك بنية تحتية لإجراء اختبارات القبول.
حاولنا الاستفادة القصوى من الأدوات المستخدمة بالفعل لتنفيذ المكون في دورة الإصدار وإطلاق مهام التشغيل: Jira و Jenkins ، على التوالي.
دورة اختبار القبول
لإجراء اختبار القبول ، حددنا الدورة التالية:
- مراقبة المهام الواردة لاختبار قبول الإصدار ،
- تشغيل مهمة Jenkins لتثبيت إصدار الإصدار على بيئة اختبار ،
- تحقق من أن الخدمة قد ارتفعت ،
- إطلاق وظيفة جينكينز مع اختبارات التكامل ،
- تحليل نتائج المدى ،
- التشغيل المتكرر للاختبار (إذا لزم الأمر) ،
- تحديث حالة المهمة - مكتمل أو معطل ، مع الإشارة إلى السبب في التعليق.
تم تنفيذ الدورة بأكملها يدويًا في كل مرة. كنتيجة لذلك ، في الإصدار العاشر من اليوم ، أردت أن أقسم أداء نفس المهام ، في أحسن الأحوال ، تحت أنفاسي ، وأمسك برأسي وأطلب من حشيشة الهر.
مراقب بوت
لقد أدركنا أن تتبع المهام الجديدة والإبلاغ عنها في Jira هي عمليات مهمة سريعة وسهلة التشغيل الآلي. لذلك كان هناك روبوت يقوم بذلك.
تأتي بيانات إنشاء التنبيهات في شكل إعلامات دفع من Jira. بعد بدء برنامج الروبوت ، توقفنا عن تحديث صفحة لوحة القيادة بمهام القبول ، وزاد عرض ابتسامة الأوتوماتون زيادة طفيفة.
جهاز يبعث نبضات صوتية
قررنا تبسيط عملية التحقق من عدم حدوث أخطاء في التجميع أو التثبيت أثناء النشر في بيئة الاختبار وأنه تم رفع الإصدار المطلوب من المكون ، وليس بعض الأخطاء الأخرى. يعطي المكون نسخته وحالته عبر HTTP. والتأكد من إرجاع الخدمة للإصدار الصحيح سيكون بسيطًا ومفهومًا إذا لم تتم كتابة مكونات مختلفة بلغات مختلفة - بعضها في Node.js ، وبعضها في C #. بالإضافة إلى ذلك ، قدمت خدماتنا الأكثر شعبية في Java أيضًا النسخة بتنسيق مختلف.
بالإضافة إلى ذلك ، كنت أرغب في الحصول على معلومات وإعلامات في الوقت الفعلي ، ليس فقط حول تغييرات الإصدار ، ولكن أيضًا حول التغييرات في توفر المكونات في النظام. لحل هذه المشكلة ، ظهرت خدمة Pinger ، التي تجمع معلومات حول حالة المكونات وإصدارها عن طريق الاستقصاء عنها دوريًا.
نحن نستخدم نموذج دفع لتسليم الرسائل - يتم نشر وكيل على كل مثيل لبيئة الاختبار ، والذي يجمع معلومات حول مكونات هذه البيئة ويخزن البيانات على عقدة مركزية كل 10 ثوانٍ. نذهب إلى هذه العقدة للحصول على الحالة الحالية - يسمح لنا هذا النهج بدعم أكثر من مائة منصة اختبار.
خزانة
لقد حان الوقت للقيام بمهام أكثر تعقيدًا - التحديث التلقائي للمكونات واختبارات التشغيل. في ذلك الوقت ، كان لدى فريقنا بالفعل 3 مقاعد اختبار في OpenStack لإجراء اختبارات القبول ، وكان من الضروري أولاً حل مشكلة إدارة موارد مقاعد الاختبار: سيكون من غير الجيد إذا كان تحديث الإصدار التالي "rolls" عند إجراء الاختبارات على النظام. يحدث أيضًا أن مقعد الاختبار تم تصحيحه ، ومن ثم يجب ألا تستخدمه للقبول.
أردت أن أكون قادرًا على رؤية حالة التوظيف ، وإذا لزم الأمر ، أغلق الحامل يدويًا طوال فترة تحليل الاختبارات الساقطة أو حتى الانتهاء من العمل الآخر.
لكل هذا ، ظهرت خدمة Locker. يحافظ على حالة منضدة الاختبار لفترة طويلة ("مشغول" / "مجاني") ، ويسمح لك بتحديد تعليق على "مشغول" ، بحيث يكون من الواضح أننا نعمل الآن على تصحيح الأخطاء أو إعادة إنشاء نسخة من بيئة الاختبار أو تشغيل الاختبارات للإصدار التالي. لقد بدأنا أيضًا في حظر المدرجات في الليل - حيث يقوم المسؤولون بتنفيذ الأعمال وفقًا لجدول زمني ، مثل النسخ الاحتياطي ومزامنة قاعدة البيانات.
عند الحظر ، يتم دائمًا ضبط الوقت الذي ينتهي بعده القفل - والآن لا يحتاج الأشخاص إلى المشاركة في إرجاع المدرجات إلى المسبح المتوفر ، ويقوم الجهاز بكل شيء.
واجب
لتوزيع الحمل بالتساوي بين أعضاء الفريق لتحليل نتائج عمليات الاختبار ، توصلنا إلى نوبات يومية. يعمل المصاحب مع مهام اختبار قبول الإصدارات ، يوزع autotests والإبلاغ عن الأخطاء. إذا أدرك المصاحب أنه لا يتعامل مع تدفق المهام ، فيمكنه طلب المساعدة من الفريق. في هذا الوقت ، يشارك بقية الفريق في مهام لا تتعلق بالإصدارات.
مع الزيادة في عدد الإصدارات ، ظهر دور المضيف الثاني ، الذي يتصل بالعنصر الرئيسي في حالة وجود عوائق أو وجود إصدارات حرجة في قائمة الانتظار. من أجل توفير معلومات حول التقدم المحرز في إصدارات الاختبار ، أنشأنا صفحة تحتوي على عدد من المهام في حالات "open" / "Running" / "انتظار استجابة في الخدمة" ، وحالة مواقف اختبار الحظر والمكونات التي يتعذر الوصول إليها على المدرجات:
يتطلب عمل الموظف المناوب التركيز ، لذلك لديه كعكة - في يوم الخدمة ، يمكنه اختيار مكان لتناول الغداء للفريق بأكمله بالقرب من المكتب. تبدو الرشاوى أثناء الخدمة ممتعة بشكل خاص: "اسمح لي أن أساعدك في فرز المهام ، واليوم سنذهب إلى
مكاني المفضل" =)
صحافي
كانت إحدى المهام التي واجهناها عندما قدمنا الساعة هي الحاجة إلى نقل المعرفة من موظف إلى آخر ، على سبيل المثال ، حول الاختبارات التي تقع على إصدار جديد أو تفاصيل تحديث أحد المكونات.
بالإضافة إلى ذلك ، لدينا ميزات جديدة للعمل.
- كانت هناك فئة من الاختبارات التي تقع في تردد أكبر أو أقل بسبب مشاكل في مقاعد الاختبار. يمكن أن يحدث السقوط بسبب زيادة وقت استجابة إحدى الخدمات أو التحميل الطويل للموارد في المتصفح. لا أريد إيقاف الاختبارات ؛ فقد استنفدت الوسائل المعقولة لزيادة موثوقيتها.
- كان لدينا مشروع تجريبي ثانٍ يحتوي على امتحانات ذاتية ، وقد نشأت الحاجة إلى تحليل عمليات مشروعين في وقت واحد ، مع النظر في تقارير ألور.
- يمكن أن يستغرق التشغيل التجريبي ما يصل إلى 20 دقيقة ، وتريد البدء في تحليل النتائج فور بدء أول قطرات. خاصة إذا كانت المهمة حرجة وكان أعضاء الفريق المسؤول عن الإفراج يقفون خلفك
، يحملون السكين في الحلق بأعين يرثى لها.
هذه هي الطريقة التي جاءت بها خدمة المراسل. فيه ندفع نتائج الاختبار التشغيلي في الوقت الفعلي أثناء عملية الاختبار. تحتوي الخدمة على قاعدة بيانات للمشكلات المعروفة أو الأخطاء التي ترتبط باختبار محدد. أيضا ، تم نشر منشور على بوابة الشركة الويكي لتقرير موجز عن نتائج التشغيل من المراسل. يعد هذا مناسبًا للمديرين الذين لا يرغبون في الاطلاع على التفاصيل الفنية التي تزخر بها واجهة المراسل أو الجاذبية.
إذا تعطل الاختبار ، يمكنك البحث في "المراسل" للحصول على قائمة بالأخطاء ذات الصلة أو إصلاح المهام. هذه المعلومات تقصر الوقت في تحليل وتسهل تبادل المعرفة حول المشاكل بين أعضاء فريقنا. يتم أرشفة سجلات المهام المكتملة ، ولكن إذا لزم الأمر ، يمكنك "إلقاء نظرة" عليها في قائمة منفصلة. من أجل عدم تحميل الخدمات الداخلية خلال ساعات العمل ، فإننا نقوم بمقابلة جيرا في الليل وأرشفة إدخالات للقضايا ذات الوضع النهائي.
كانت المكافأة من مقدمة Reporter هي ظهور قاعدة بيانات تعمل ، والتي يمكنك من خلالها تحليل تواتر السقوط ، واختبارات التصنيف حسب مستوى ثباتها أو "فائدتها" من حيث عدد الأخطاء التي تم العثور عليها.
التشغيل التلقائي
بعد ذلك ، انتقلنا إلى التشغيل التلقائي لإطلاق الاختبارات عندما يتعلق الأمر بمسألة اختبار قبول الإصدار. لهذا الغرض ، تمت كتابة خدمة التشغيل التلقائي ، والتي تتحقق مما إذا كانت هناك مهام قبول جديدة في جيرا ، وإذا كان الأمر كذلك ، فإنها تحدد اسم المكون وإصداره بناءً على محتويات المهمة.
بالنسبة للمهمة ، يتم تنفيذ العديد من الخطوات:
- قم بقفل أحد مقاعد الاختبار المجانية في خدمة Locker ،
- بدء تثبيت المكون الضروري في جينكينز ، انتظر حتى يتم رفع المكون مع الإصدار المطلوب ،
- تشغيل الاختبارات
- انتظر انتهاء الاختبار ، في عملية تنفيذها يتم دفع جميع النتائج إلى مراسل ،
- نسأل ريبورتر عن عدد الاختبارات الفاشلة ، باستثناء تلك التي سقطت بسبب مشاكل معروفة ،
- إذا انخفض 0 - فنحن ننقل مهمة اختبار القبول إلى "إنهاء" وإنهاء العمل معها. كل شيء جاهز =)
- إذا كانت هناك اختبارات "حمراء" - فنحن نترجم المهمة إلى "انتظار" وننتقل إلى "المراسل" لتحليلها.
يتم التبديل بين المراحل بواسطة مبدأ آلة الحالة المحدودة. كل مرحلة في حد ذاتها تعرف شروط الانتقال إلى المرحلة التالية. يتم تخزين نتائج المرحلة في سياق المهمة ، وهو أمر شائع لمراحل مهمة واحدة.
كل هذا يسمح لك بنقل الإصدارات تلقائيًا على طول خط أنابيب النشر ، وفقًا لذلك ، فإن 100 بالمائة من الاختبارات تكون خضراء. ولكن ماذا عن عدم الاستقرار الناجم عن عدم وجود مشاكل في المكون ، ولكن بسبب الميزات "الطبيعية" في اختبارات واجهة المستخدم أو بسبب تأخر الشبكة المتزايد في منصة الاختبار؟
للقيام بذلك ، قمنا بتطبيق آلية إعادة المحاولة ، والتي يستخدمها كثير من الناس ، لكن القليل منهم يتعرف على ذلك. يتم تنظيم عمليات الاستعادة كعملية تسلسلية للاختبارات في Jenkins Pipeline.
بعد التشغيل ، نطلب قائمة من الاختبارات الفاشلة من مراسل من جينكينز - وإعادة تشغيل الاختبارات الفاشلة فقط. بالإضافة إلى ذلك ، نقوم بتقليل عدد مؤشرات الترابط عند بدء التشغيل. إذا لم ينخفض عدد الاختبارات المسقطة مقارنة بالفترة السابقة ، فسننهي الوظيفة على الفور. في حالتنا ، يتيح لنا هذا النهج لإعادة التشغيل زيادة نجاح اختبار القبول بنحو 2 مرات.
كتلة سريعة
سمح لنا نظام اختبار القبول الناتج بإجراء أكثر من 60 ٪ من الإصدارات دون تدخل بشري. ولكن ماذا تفعل مع البقية؟ إذا لزم الأمر ، يقوم المشرف بإنشاء تقرير خطأ عن المكون قيد الاختبار أو مهمة إصلاح الاختبارات إلى فريق التطوير. في بعض الأحيان - يرسم خطأ في تكوين طاولة الاختبار إلى قسم التشغيل.
غالبًا ما تمنع مهام تصحيح الاختبارات مرور الاختبار التلقائي بشكل صحيح ، نظرًا لأن الاختبارات غير الملائمة ستكون دائمًا "حمراء". يتحمل المختبرون من فرق التطوير مسؤولية كتابة اختبارات جديدة وتحديث الاختبارات الحالية - إجراء تغييرات من خلال طلبات السحب إلى المشروع من خلال اختبارات تلقائية. تخضع هذه التعديلات لمراجعة إلزامية ، تتطلب بعض الوقت من المراجع ومن المؤلف ، وأريد حظر الاختبارات غير ذات الصلة مؤقتًا حتى تتم ترجمة المهمة إلى وضعها النهائي.
أولاً ، قمنا بتطبيق آلية إغلاق استنادًا إلى تعليقات توضيحية لطرق الاختبار. بعد ذلك ، اتضح أنه نظرًا لوجود مراجعة إلزامية للكود ، فإن الحظر على الكود ليس دائمًا ملائمًا وقد يستغرق وقتًا أطول مما نود.
لذلك ، نقلنا قائمة المهام حظر الاختبارات إلى خدمة جديدة مع صفحة ويب - كتلة سريعة. لذلك يمكن لأعضاء الفريق المسؤول عن المكون منع الاختبار بسرعة. قبل التشغيل ، نذهب إلى هذه الخدمة ونحصل على قائمة من الاختبارات المعزولة ، والتي نترجمها إلى حالة تم تخطيها.
النتائج
لقد انتقلنا من قبول الإصدارات في الوضع اليدوي إلى عملية تلقائية بالكامل تقريبًا ، والتي تكون قادرة على إجراء اختبار القبول لأكثر من 50 إصدارًا يوميًا. يساعد هذا الشركة على تقليل الوقت الذي يستغرقه نشر التغييرات ، ويمكن لفريقنا العثور على موارد لتجربة أدوات الاختبار وتطويرها.
في المستقبل ، نخطط لزيادة موثوقية العملية ، على سبيل المثال ، عن طريق توزيع الطلبات بين زوج من مثيلات كل خدمة من القائمة أعلاه. سيسمح لك ذلك بتحديث الأدوات دون توقف وإدراج ميزات جديدة فقط لجزء من اختبارات القبول. بالإضافة إلى ذلك ، فإننا نولي الاهتمام لتحقيق الاستقرار في الاختبارات بأنفسهم. في مجال التطوير ، مولد بطاقات لاختبارات إعادة البناء بأقل معدل نجاح.
لن يؤدي تحسين موثوقية الاختبارات إلى زيادة الثقة بها فحسب ، بل سيسرع أيضًا في اختبار الإصدارات بسبب عدم إعادة تشغيل البرامج النصية الساقطة.