يعد تصحيح الأخطاء أمرًا مملاً ، ولكنه جزء إلزامي من أي تطور ، ولا يريد الجميع القيام بذلك. كيفية تحويل bugfixing إلى شيء مثير؟ رتب منافسة! في هذا المنشور ، سنتحدث بالتفصيل عن "ماراثون bugfix" الذي يعمل على مدار 24 ساعة - بدءًا من التحضير الأولي وصولاً إلى تنفيذ الالتزامات الأخيرة بعد منح الفائزين.
مصاب بالفكرة
ازداد حجم تطوير تطبيق Sberbank Online بشكل كبير خلال العام الماضي. إلى جانب هذا ، بدأت الأخطاء الصغيرة تتراكم ، والتي لم تنعكس بأي شكل من الأشكال على المقاييس الرئيسية. لكننا فهمنا أن هذه قنبلة موقوتة ويجب عمل شيء معها.
لقد
استلهمنا من كيفية حل زملائنا في
Avito لمثل هذه المشاكل ، وقررنا تنظيم هجوم كبير على البق بتنسيق الباتاجون - مع الأخذ في الاعتبار هيكل التطوير وثقافة وتفاصيل التدفق.
كان من الضروري ترتيب كل شيء حتى يرغب الرجال أنفسهم في المشاركة في الباتاجون وإثبات برودةهم دون توجيهات من الأعلى. للقيام بذلك ، يجب أن تتمتع المنافسة بجو بارد. قررنا أن نبتكر أسلوبًا مميزًا ، وهو أمر يمكن التعرف عليه بشأن الأخطاء. البق هي البق. من يدمر الحشرات في الحياة العادية؟ المطهرات رجال يرتدون سترات حماية كيميائية صفراء. أين أضاءوا في السنوات الأخيرة؟ في سلسلة شهيرة عن مدرس الكيمياء. هناك أساس ، ننتهي بالأنشطة. قاموا بتنظيم دورة ألعاب فيديو ، مسابقة مع جوائز ، ترشيحات فردية رائعة ... وبالطبع ، الكثير من الطعام اللذيذ. لكن الشيء الرئيسي ، بغض النظر عما قد يقوله المرء ، هو مسابقة القضاء على الأخطاء. تم تذكير هذا بلوحة تحكم بواجهة ويب ، توضح تقدم الفرق ، ومواقعها الحالية ، وعدد النقاط ، وما إلى ذلك. ناقشنا كل شيء مع قادة الفريق - وافقوا على خططنا.
Android مقابل iOS - غير أمين للغاية
أولاً ، أردنا دفع مطوري Sberbank Online Android مع زملائهم في iOS ، للعب على منافسة الأنظمة الأساسية. ولكن في هذه العملية ، أدركت المنظمات أن هذا ليس الحل الأفضل ، لأن المنصات تعمل من الناحية الفنية في ظروف غير متكافئة. حدث ذلك أنه على iOS ، تكون البنى أسرع ويتم تشغيل الاختبارات التلقائية.
ثم قمنا بتغيير التنسيق وقمنا بتشكيل فرق مختلطة: خمسة من مطوري Android و iOS لكل منهم. في السابق ، تم اختيار القباطنة من بين المطورين الاستباقيين للمساعدة في تشكيل الفرق. اتضح تسعة فرق. وعلى الرغم من حقيقة أننا توصلنا إلى مسألة الحديد من وجهة نظر اللعب النظيف ، إلا أنه لا يزال يتعين علينا التأكد من أن القيود الأخرى لن تقف في طريق جيشنا الذي يعمل على إصلاح الأخطاء.
كان البحث التالي هو اختيار تاريخ باجاتون. تختلف تواريخ الإصدار لكل نظام أساسي - فقد تم اختيارها بحيث يشعر الجميع بالراحة. حاولنا جعل التاريخ قريبًا قدر الإمكان من التاريخ الذي تم فيه تعيين مرشح الإصدار.
بالإضافة إلى ذلك ، تقوم باجاتون بتحميل البنى التحتية للمنصة بشكل كبير. عندما تكون هناك منافسة ، تقوم بإصلاح الأخطاء بشكل أسرع ، ينطلق عدد طلبات السحب. قبل شهر ونصف من الباجاتون ، كان هناك خطر من عدم قدرة معداتنا على التأقلم مع القمم المتوقعة. ولكن في تلك اللحظة كنا نتوقع حديدًا جديدًا ، وقد وصل في الوقت المناسب. تمكنا من ربط وتكوين وتعزيز البنية التحتية لعرض النطاق الترددي لكلا المنصتين عدة مرات.
خط الأنابيب - كيف لا تخفض كل شيء إلى أنبوب
تم عمل كل شيء هنا على النحو التالي: قبل بداية الباتاجون من تطورنا ، أخذنا الفرع الذي كان على الفرق العمل فيه. تم صب الكثير من طلبات السحب مع البق الثابتة خلال الباتاجون. تم تشغيل الاختبارات التلقائية على كل منها ، وراجع المطورون طلبات السحب ، وفحص المختبرون الإصدارات الجديدة لإصلاح الخطأ. وهكذا كل 24 ساعة من المسابقة.
كان من الضروري أيضًا توزيع حمولة المختبرين. لقد وضعنا مخططًا لكل ساعة للعدد المتوقع لطلبات السحب في فترة 24 ساعة باجاتون - اعتمادًا على عدد المشاركين ، وتحميل الخادم ، وأنشطة الطرف الثالث ، وما إلى ذلك. مقارنة بمتوسط أداء المختبرين وعدد الساعات الفعالة لكل باغاتون مصاحب. وزعنا "الواجب" بحيث كانت الخطوط حتى صباح السبت أقل عدد ممكن. بشكل عام ، حصلوا على الخلط.
في الوقت نفسه ، أخذنا في الاعتبار أنه بعد Bagaton كان من الضروري البدء على الفور في اختبار الانحدار من أجل تقييم جودة الفرع في أقرب وقت ممكن والبت في ضخه في الفرع dev. هذا عبء إضافي على المختبرين.
مراجعة الميزات
كان من المهم جدًا بالنسبة لنا ليس فقط إصلاح الأخطاء ، ولكن للقيام بذلك نوعيًا. توفر ثلاثة إجراءات التحقق من الرمز الذي أرسله المطورون في طلبات السحب. لكي ينفجر الرمز ، يجب أن يجتاز بنجاح:
- قام ثلاثة مطورين ذوي خبرة بمراجعة الكود والموافقة عليه.
- تعطل الرمز بشكل طبيعي ولم يفشل الاختبارات الذاتية ؛
- بعد البناء والتسريب ، لا يستأنف الخلل في التجميع في الظروف الموصوفة.
كنا نخشى أنه في الوضع التنافسي لن يراجع أحدهم الآخر. وداخل الفريق لا يمكنك ترك تعليق. لذلك ، قرروا عدم اختراع أي شيء والتصرف على التدفق القياسي ، كما هو الحال في وضع العمل: مراجعة تعسفية تعسفية - أيا كان حرًا ، يأخذ العملية على عاتقه.
كان من الضروري أيضًا التتبع بحيث لا تذهب المراجعات إلى قائمة الانتظار. من أجل لعبها بشكل آمن ، جذبنا الموقّعين إلى المراجعة (حتى أولئك الذين لم يشاركوا في الباجاتون نفسها) وذكّرنا المشاركين بنشاط بالتوجه نحو الجودة. حصل أحد كبار مطوري iOS ، بالتوازي مع إصلاح الأخطاء لفريقه ، في يوم واحد على 80 طلب سحب - قرأ وفهم. هذا حقا الكثير!
نختار الأخطاء ونقيمها
أخذنا أخطاء ذات أولوية منخفضة ، وأزلنا القمامة الواضحة عن طريق الملصقات والتواريخ. في المجموع ، ظهر 490 حشرة - معظمها صغيرة ومتوسطة ، والتي لم تصل إليها اليدين بسبب مهام أكثر أهمية. هذه كلها تافهة وقاصر عاقل:
- الأخطاء التي انتقلت مرارًا وتكرارًا من إصدار إلى آخر
- خلل البق على طلبات المستخدم
- تحطم طازج
- البق الانحدار
- الأخطاء التي تؤثر على تجربة المستخدم
تم تقسيم جميع البق إلى ثلاث موجات وفقًا لأولوية الإغلاق:
- الموجة الأولى - حوالي 230 البق
- الموجة الثانية - حوالي 150 البق
- الموجة الثالثة (احتياطي) - حوالي 110 بق
تم تقييم العيوب ليس من خلال التعقيد ، ولكن من خلال الأهمية الحرجة للأعمال التجارية. الأكثر أهمية هي "مصطنع" ويتم وضعها مؤقتًا في "مانع" و "حاسم" ذات أولوية. كلما زادت أولوية الخطأ ، تم منح المزيد من النقاط له. لم يؤخذ التعقيد في الاعتبار - حدث أن أغلق مانع الأخطاء في 20 دقيقة ، والتافهة - في 4 ساعات. لعلة واحدة ، يمكنك كسب من 1 إلى 7 نقاط.
احتفظنا بنتيجة كل فريق للأخطاء المغلقة وفقًا لقيمتها في قواعد الباتاجون. إذا كان لدى الفرق وقت ، أخذوا في العمل العيب التالي. جعل الدافع من خلال القيمة من الممكن إغلاق الأخطاء الأكثر أهمية في المقام الأول.
كيفية إغلاق الخلل
قسمنا الموجة الأولى من الأخطاء إلى 11 مجموعة (بهامش) ، متساوية في عدد النقاط وفي نسبة Android و iOS. الموجة الأولى هي البق "باهظ الثمن" ، الأولوية مع زيادة التكلفة. للبحث المريح في Jira ، قمنا بتعيين لهم الملصقات المناسبة. تم إطلاق حوالي 20 حشرة في كل مجموعة.
في بداية الباجاتون ، جمعنا قادة الفرق ولعبنا التسميات. علاوة على ذلك ، قام القبطان في المرشح بتعيين التسمية المطلوبة وتوزيع الأخطاء المقابلة داخل الفريق. لذلك تمكنا من القضاء على إصلاح الأخطاء الفوضوية ، حيث سيأخذ الرجال ببساطة ما هو أكثر فهمًا لهم.
في الساعات الأربع الأولى ، مُنحت الفرق نقاطًا فقط للأخطاء التي تحمل ملصقات المجموعة التي سقطت لهم لتحديد إيقاع معين. عندما انتهى الوقت ، مرت البق الذي لا يزال مفتوحًا في الموجة الثانية ، مضيفًا إلى الأنواع الأخرى التي كان من المنطقي إغلاقها داخل الباتاجون.
بحلول الساعة 19:00 ، دخلت جميع الأخطاء غير المغلقة في الموجة الثالثة - بالإضافة إلى تلك الأخطاء التي تم التخطيط لها بالفعل هناك. ونتيجة لذلك ، كان لدينا في المساء أخطاء "سريعة" ستغلق في التدفق المعتاد: ذاكرة التخزين المؤقت والأخرى الحالية ، التي تم تفريغها حرفيا قبل يوم واحد من الباتاجون ، بالإضافة إلى الأخطاء ذات الأولوية الأقل. ذهبت كل الموجات الثلاث إلى العمل. ونتيجة لذلك ، تم إغلاق 286 من بين 493 من الحشرات المختارة لباجاتون.
يوحد باجاتون
يقع مقر Bagaton في غرفة الاجتماعات لدينا ، وكانت هناك أيضًا مسابقات ودورة ألعاب فيديو. لم تكن الفرق محدودة ، متناثرة في أي مكان مناسب لهم. ونتيجة لذلك ، اكتشف البنك بأكمله عن الباجاتون. قال أحد المنتجين من الطابق الرابع: "سألتقي في الطابق الرابع عشر ، أبحث عن غرفة الاجتماعات المناسبة. فجأة أفهم أنني رأيت للتو الوجوه المألوفة ، سأعود - مطوري يجلسون مع التماثيل بقوة وقوة ، ولا يهتمون بي. ها - أعتقد - لن يختبئوا من مالك المنتج الخاص بهم وأكثر من 10 طوابق ، حسنًا ، اجلس بالفعل ، إصلاح الخطأ هو الشيء الصحيح ".
كان هناك فريق جاء فيه Android واحد فقط إلى الباجاتون وفي نفس الوقت ستة مطورين أقوياء لنظام iOS. لقد أخرجنا هذا الفريق بشكل استثنائي حزمة أخرى مع أخطاء iOS.
بالإضافة إلى ذلك ، جاء سبعة مطورين من المناطق إلى باجاتون. التقى البعض بفرقهم لأول مرة ، والتي لم يروها من قبل إلا عن طريق التداول بالفيديو. كان من الرائع مشاهدة كيفية انضمام هؤلاء الأشخاص إلى العملية بنشاط.
كيف تم تقييم النتائج؟
لما يقرب من مائة مطور ، كان لدينا 15 اختبارًا فقط. وفي الليل هناك أربعة على الإطلاق. كلها لم تكن كافية ، لذلك استمر الاختبار في اليوم التالي. كان المختبرون هم من منحوا النقاط للفرق ، لذلك قمنا بإزالتها من الفريق من أجل القضاء على التحيز. في سير العمل العادي ، يمكن للمختبر الاتصال بالمطور ومعرفة: "اسمع ، يا صاح ، هناك مثل هذه المشكلة ...". في باجاتون كان صارمًا: يجب على المختبرين لف كل ما لا يمر بوضوح.
لذلك تمكنا من رؤية أن بعض المطورين لا يعملون في التدفق المقبول. أصبح Hackathon نوعًا من المحفز لجميع الانحرافات. تمكن أولئك الذين يعملون بوضوح في التدفق من اجتياز الاختبار في الموجة الأولى والحصول على نقاط. كل من لم يتطابق حقًا دخل في قائمة الانتظار ، التي قاموا بجمعها بالفعل بعد الباجاتون. حصلت على 60 حشرة.
الحوادث
بشكل عام ، كل شيء سار كالمعتاد ، كانت الحوادث نموذجية وتم حلها في نظام عمل. عندما انكسر شيء ما ، تحولت بعض العلامات على الفور من إصلاح الخطأ إلى القضاء على الحادث.
كان هناك حادث واحد مضحك. عند إعداد لوحة القيادة ، وصفنا المخاطر المحتملة: الوصول إلى Jira ، وتحديثات متجددة ، وما إلى ذلك. أبلغوا جميع المسؤولين أنه لوقت الباتاجون كان من الضروري تعليق جميع أعمال الصيانة وتحديثات Jira والخوادم. إنشاء حسابات النسخ الاحتياطي للوصول إلى Jira. وفجأة في حوالي الساعة 18:00 ندرك أن لوحة التحكم توقفت عن جمع البيانات. كانت الافتراضات مختلفة. ربما لم يأخذوا في الاعتبار بعض بروتوكول الأمان؟ كان السبب غير متوقع. مؤسستنا كبيرة جدًا ، ليس من الممكن دائمًا الحصول على معلومات كاملة حول جميع العمليات المخطط لها. تم نشر لوحة القيادة الخاصة بنا على جهاز افتراضي على أحد الخوادم الثانوية. اتضح أنه في هذا اليوم ، مساء الجمعة ، تم فصل هذا الخادم ، وفقًا لخطة غير معروفة ، فعليًا من المنفذ ، وتم تحميله في السيارة وإرساله إلى الإقامة الدائمة في مركز البيانات الجديد الخاص بنا. ونتيجة لذلك ، بحلول صباح يوم السبت ، كان علينا جمع جميع البيانات وحساب النقاط في الوضع اليدوي.
دمج الفروع والنتائج الأخرى
في وضع التشغيل العادي ، يتم تشغيل الفرع بالكامل يدويًا بأكثر من 800 حالة اختبار. يقوم فريق كامل من المختبرين باختبار التراجع بدوام كامل في أسبوعين. لم نتمكن من الاستمرار في التطور دون تغيير لفترة طويلة. لتقليل وقت الاختبار ، اخترنا حالات الاختبار الرئيسية لصحة التطبيق - حوالي 107. حتى نهاية يوم الاثنين ، قادوا 80٪ من نظام iOS ، و 50٪ من Android ولم يكشفوا عن خطأ حرج واحد. قررنا أنه يمكن دمج الفروع.
من أصل 286 حشرة تم إغلاقها على الباجاتون ، تم إصلاح 182 حشرة. والباقي عبارة عن عبوات حمراء ليست ذات صلة لأسباب مختلفة ، والأخطاء (في مكان ما تغير التصميم أو الوظيفة بالفعل). هذه الأخطاء ليست حاسمة ، ولكن الآن لن تحتاج إلى تشتيت الانتباه ويمكنك التركيز بهدوء على المهام المهمة.
أيضا ، العديد ، بعد نتائج الباجاتون ، كان لديهم سؤال: كم عدد الأخطاء التي صنعناها؟ فقط ثمانية أخطاء على iOS وسبعة أخطاء على Android.
من المهم بالنسبة لنا أن يشعر المطورون بالمسؤولية عن رمز المنتج على قدم المساواة مع أعضاء الفريق الآخرين. هذا مهم في أي تطور ، ولكن في التطوير الموزع يصبح شرطًا أساسيًا للعمل الناجح. وفي رأينا ، تمكنا من زيادة مستوى نفس الملكية وروح الفريق. كانت النتيجة قصة مع ربح من الأرباح: في وقت قصير قمنا بإصلاح مجموعة من الأخطاء ، وتراكم التحميلات ، وضخ مهارات الفريق وحصلنا على الكثير من المعجبين.
المواد التي أعدها فريق منصة الأعمال الرقمية Sberbank