Sberbank में "ब्रेकिंग बग": प्रति दिन बग की सात दिन की दर को कैसे ठीक करें

बगफिक्सिंग किसी भी विकास का एक थकाऊ, लेकिन अनिवार्य हिस्सा है, और हर कोई इसे नहीं करना चाहता है। बगफाइकिंग को किसी रोमांचक चीज़ में कैसे बदलें? एक प्रतियोगिता की व्यवस्था करें! इस पोस्ट में, हम अपने 24 घंटे के "बगफिक्स मैराथन" के बारे में विस्तार से बात करेंगे - प्रारंभिक तैयारी से लेकर रेकिंग करने के बाद विजेताओं को पुरस्कार देने के बाद।



विचार से संक्रमित


हमारे Sberbank Online एप्लिकेशन के विकास का पैमाना पिछले एक साल में काफी बढ़ा है। इसके साथ ही, छोटे कीड़े जमा होने लगे, जो कि किसी भी तरह से मुख्य मैट्रिक्स पर प्रतिबिंबित नहीं होते थे। लेकिन हम समझ गए कि यह एक टाइम बम है और इसके साथ कुछ करने की जरूरत है।

हम इस बात से प्रेरित थे कि हमारे अवितो सहयोगियों ने इस तरह की समस्याओं को कैसे हल किया, और हमने बैगनटन प्रारूप में कीड़े पर एक बड़े हमले का आयोजन करने का निर्णय लिया - हमारे विकास संरचना, संस्कृति और प्रवाह की बारीकियों को ध्यान में रखते हुए।



यह सब कुछ व्यवस्थित करने के लिए आवश्यक था ताकि लोग खुद एक बैगन में भाग लेना चाहते थे और ऊपर से निर्देशों के बिना अपनी शीतलता साबित कर सकें। ऐसा करने के लिए, प्रतियोगिता में एक शांत वातावरण होना चाहिए। हमने एक विशेष शैली के साथ आने का फैसला किया, जो कि बग के बारे में कुछ पहचानने योग्य है। कीड़े कीड़े हैं। साधारण जीवन में कौन कीड़े को नष्ट करता है? रोगाणु पीले रासायनिक संरक्षण सूट के लोग हैं। हाल के वर्षों में उन्हें कहाँ जलाया गया है? एक रसायन विज्ञान शिक्षक के बारे में एक लोकप्रिय श्रृंखला में। एक आधार है, हम गतिविधियों के साथ समाप्त करते हैं। उन्होंने एक वीडियो गेम टूर्नामेंट, पुरस्कारों के साथ एक प्रश्नोत्तरी, शांत व्यक्तिगत नामांकन ... और निश्चित रूप से, बहुत सारे स्वादिष्ट भोजन का आयोजन किया। लेकिन मुख्य बात, जो कोई भी कह सकता है, कीड़े को खत्म करने की प्रतियोगिता है। यह एक वेब इंटरफेस के साथ डैशबोर्ड की याद दिलाता था, जो टीमों की प्रगति, उनके वर्तमान पदों, अंकों की संख्या आदि को दर्शाता था। हमने टीम के नेताओं के साथ सब कुछ पर चर्चा की - उन्होंने हमारी योजनाओं को मंजूरी दी।

एंड्रॉइड बनाम आईओएस - इतना बेईमान


सबसे पहले, हम प्लेटफॉर्म की प्रतिद्वंद्विता पर खेलने के लिए अपने आईओएस सहयोगियों के साथ सर्बैंक ऑनलाइन एंड्रॉइड डेवलपर्स को आगे बढ़ाना चाहते थे। लेकिन इस प्रक्रिया में, संगठनों ने महसूस किया कि यह सबसे अच्छा समाधान नहीं है, क्योंकि तकनीकी रूप से प्लेटफार्म असमान स्थितियों में काम करते हैं। ऐसा हुआ कि iOS पर, बिल्ड तेजी से होते हैं और ऑटोटेस्ट चलाया जाता है।

फिर हमने प्रारूप को बदल दिया और मिश्रित टीमों को बनाया: प्रत्येक पाँच एंड्रॉइड और आईओएस डेवलपर्स। पहले, कप्तानों को सक्रिय टीम में मदद करने के लिए प्रोएक्टिव डेवलपर्स के बीच से चुना गया था। इसने नौ टीमें बनाईं। और इस तथ्य के बावजूद कि हमने निष्पक्ष खेल के दृष्टिकोण से लोहे के मुद्दे का पता लगाया, हमें अभी भी यह सुनिश्चित करना था कि बग फिक्सरों की हमारी सेना के रास्ते में अन्य प्रतिबंध नहीं लगेंगे।

अगली खोज बैगन डेट की पसंद थी। प्रत्येक प्लेटफ़ॉर्म के लिए रिलीज़ की तारीखें अलग-अलग हैं - उन्हें चुना गया ताकि सभी लोग सहज हों। हमने उस दिनांक को यथासंभव संभव बनाने की कोशिश की जब रिलीज उम्मीदवार को सौंपा गया हो।

इसके अलावा, बैगटन प्लेटफॉर्म इन्फ्रास्ट्रक्चर को भारी पड़ता है। जब एक प्रतियोगिता होती है, जो तेजी से कीड़े को ठीक करता है, तो पुल अनुरोधों की संख्या बंद हो जाती है। बैगाटन से डेढ़ महीने पहले, एक जोखिम था कि हमारे उपकरण अनुमानित चोटियों का सामना नहीं कर सकते थे। लेकिन उस समय हम नए लोहे की उम्मीद कर रहे थे, और यह समय में ही आ गया। हम कई बार दोनों प्लेटफार्मों के बैंडविड्थ बुनियादी ढांचे को जोड़ने, कॉन्फ़िगर करने और मजबूत करने में कामयाब रहे।



पाइप लाइन - कैसे एक पाइप में सब कुछ कम करने के लिए नहीं


यहां सब कुछ निम्नानुसार किया गया था: हमारे विकास से बैगटन की शुरुआत से तुरंत पहले, हमने उस शाखा को लिया जिसमें टीमों को काम करना था। बैगाटन के दौरान फिक्स्ड बग के साथ बहुत सारे अनुरोधों को इसमें डाला गया था। ऑटोटेस्ट्स उनमें से प्रत्येक पर चलाए गए थे, डेवलपर्स ने पुल अनुरोधों की समीक्षा की, और बग को ठीक करने के लिए परीक्षकों ने नए बिल्ड की जांच की। और इसलिए प्रतियोगिता के सभी 24 घंटे।

परीक्षकों के भार को वितरित करना भी आवश्यक था। हमने प्रतिभागियों की संख्या, सर्वर लोड, तृतीय-पक्ष गतिविधियों, आदि के आधार पर 24 घंटे के बैगटन अंतराल में पुल अनुरोधों की अनुमानित संख्या का एक घंटे का चार्ट बनाया। परीक्षकों के औसत प्रदर्शन और प्रत्येक के साथ प्रभावी बैगटन की संख्या की तुलना में। हमने "ड्यूटी" वितरित की ताकि शनिवार की सुबह तक लाइनें यथासंभव कम हो सकें। सामान्य तौर पर, वे भ्रमित हो गए।

उसी समय, हमने इस बात पर ध्यान दिया कि बैगन के बाद शाखा की गुणवत्ता का जल्द से जल्द मूल्यांकन करने और देव शाखा में इसके जलसेक पर निर्णय लेने के लिए तुरंत प्रतिगमन परीक्षण शुरू करना आवश्यक था। यह परीक्षकों पर एक अतिरिक्त बोझ है।



सुविधाएँ समीक्षा


हमारे लिए न केवल बग को ठीक करना, बल्कि गुणात्मक रूप से करना बहुत महत्वपूर्ण था। तीन प्रक्रियाएं डेवलपर्स द्वारा भेजे गए कोड के सत्यापन को पुल अनुरोधों में प्रदान करती हैं। कोड को स्नैप करने के लिए, उन्हें सफलतापूर्वक पास करना होगा:

  • तीन अनुभवी डेवलपर्स ने कोड की समीक्षा की और मंजूरी दी।
  • कोड सामान्य रूप से दुर्घटनाग्रस्त हो गया और ऑटोटेस्ट में विफल नहीं हुआ;
  • निर्माण और जलसेक के बाद, वर्णित शर्तों पर विधानसभा में बग फिर से शुरू नहीं होता है।

हमें डर था कि प्रतिस्पर्धी मोड में कोई भी एक-दूसरे की समीक्षा नहीं करेगा। और टीम के अंदर आप एक समीक्षा नहीं छोड़ सकते। इसलिए, उन्होंने कुछ भी आविष्कार नहीं करने और मानक प्रवाह पर कार्य करने का फैसला किया, जैसा कि कार्य मोड में है: एक मनमाना क्रॉस-रिव्यू - जो कोई भी स्वतंत्र है, वह इस प्रक्रिया को खुद पर लेता है।

यह ट्रैक करना भी आवश्यक था ताकि समीक्षा कतार में न जा सके। इसे सुरक्षित रूप से चलाने के लिए, हमने हस्ताक्षरकर्ताओं को समीक्षा के लिए आकर्षित किया (यहां तक ​​कि जिन्होंने स्वयं बैगन में भाग नहीं लिया था) और सक्रिय रूप से गुणवत्ता पर उन्मुखीकरण के प्रतिभागियों को याद दिलाया। एक वरिष्ठ आईओएस डेवलपर, एक दिन में अपनी टीम के लिए बग फिक्स करने के समानांतर, 80 पुल अनुरोधों के माध्यम से मिला - उसने पढ़ा और समझा। यह वास्तव में बहुत कुछ है!


हम बग का चयन और मूल्यांकन करते हैं


हमने कम-प्राथमिकता वाले कीड़े ले लिए, हमने लेबल और तिथियों द्वारा स्पष्ट कचरा को समाप्त कर दिया। कुल में, 490 कीड़े निकले - ज्यादातर छोटे और मध्यम, जो अधिक महत्वपूर्ण कार्यों के कारण हाथ तक नहीं पहुंचे। ये सभी समझदार हैं और नाबालिग हैं:

  • बग जो बार-बार संस्करण से संस्करण में चले गए हैं
  • उपयोगकर्ता के अनुरोध पर कीड़े घाव हो जाते हैं
  • ताजा दुर्घटना
  • प्रतिगमन कीड़े
  • बग जो UX को प्रभावित करते हैं

सभी बग को बंद करने की प्राथमिकता के अनुसार तीन तरंगों में विभाजित किया गया था:

  • पहली लहर - लगभग 230 बग
  • दूसरी लहर - लगभग 150 बग
  • तीसरी लहर (रिजर्व) - लगभग 110 बग

दोषों का मूल्यांकन जटिलता से नहीं, बल्कि व्यवसाय के लिए आलोचनात्मकता से किया गया था। सबसे महत्वपूर्ण "कृत्रिम रूप से" और अस्थायी रूप से प्राथमिकता "अवरोधक" और "महत्वपूर्ण" में रखा जाता है। बग की प्राथमिकता जितनी अधिक होगी, उसके लिए उतने अधिक अंक प्रदान किए गए। जटिलता को ध्यान में नहीं रखा गया - यह हुआ कि बग अवरोधक 20 मिनट में बंद हो गया, और तुच्छ - 4 घंटे में। एक बग के लिए, आप 1 से 7 अंक कमा सकते हैं।

हमने बैगनटन नियमों में उनके मूल्य के अनुसार प्रत्येक टीम का स्कोर बंद कीड़े के लिए रखा। यदि टीमों के पास समय था, तो वे निम्नलिखित दोष को काम में लेती थीं। मूल्य के माध्यम से प्रेरणा ने पहले स्थान पर अधिक महत्वपूर्ण बग को बंद करना संभव बना दिया।



कीड़े कैसे बंद करें


हमने बग की पहली लहर को 11 समूहों (एक मार्जिन के साथ) में, अंकों की संख्या में बराबर और एंड्रॉइड और आईओएस के अनुपात में विभाजित किया है। पहली लहर "महंगी" कीड़े, बढ़ी हुई लागत के साथ प्राथमिकता वाले हैं। जीरा में सुविधाजनक खोज के लिए, हमने उन्हें उपयुक्त लेबल दिए। प्रत्येक समूह में लगभग 20 बग जारी किए गए थे।

बैगनटन की शुरुआत में, हमने टीम के कप्तानों को इकट्ठा किया और लेबल खेला। इसके अलावा, अपने फिल्टर में कप्तानों ने वांछित लेबल को नामित किया और टीम के भीतर संबंधित बगों को वितरित किया। इसलिए हम अराजक बगफिक्सिंग को खत्म करने में कामयाब रहे, जहां लोग बस वही लेंगे जो उनके लिए अधिक समझ में आता है।

पहले चार घंटे, टीमों को केवल विशिष्ट ताल सेट करने के लिए गिर गए समूह के लेबल के साथ बग के लिए अंक प्रदान किए गए थे। जब समय समाप्त हो गया था, तब भी खुले बग्स दूसरी लहर में गुज़रे, दूसरों के लिए जो बैगन के भीतर बंद होने का मतलब था।

19:00 तक, सभी अछूता कीड़े तीसरी लहर में चले गए - उन बगों के अलावा जो पहले से ही वहां योजनाबद्ध थे। नतीजतन, शाम के लिए हमारे पास "तेज" कीड़े थे जो सामान्य प्रवाह में बंद हो जाएंगे: कैश और चालू वाले, बैगन से एक दिन पहले शाब्दिक रूप से लोड किए गए, साथ ही सबसे कम प्राथमिकता वाले कीड़े। तीनों लहरें काम पर चली गईं। परिणामस्वरूप, बैगनटन के लिए 493 चयनित बगों में से 286 बंद हो गए।



बागटन ने एकजुट किया


बागटन मुख्यालय हमारे सम्मेलन कक्ष में स्थित था, वहाँ क्विज़ और एक वीडियो गेम टूर्नामेंट भी थे। टीमें सीमित नहीं थीं, उनके लिए जहां भी सुविधाजनक था, बिखरे हुए थे। परिणामस्वरूप, पूरे बैंक को बैगन के बारे में पता चला। चौथी मंजिल से एक उत्पाद-ओनर ने कहा: "मैं 14 वीं मंजिल पर मिलने जा रहा हूं, सही बैठक कक्ष की तलाश कर रहा हूं। अचानक मैं समझता हूं कि मैंने अभी-अभी परिचित चेहरे देखे हैं, मैं वापस आ रहा हूं - मेरे डेवलपर्स शायद और मुख्य के साथ मूर्तियों पर बैठे हैं, और मेरे लिए शून्य ध्यान दे रहे हैं। हा - मुझे लगता है - वे अपने उत्पाद के मालिक और 10 से अधिक मंजिलों से नहीं छुपेंगे, ठीक है, पहले से ही बैठो, बगफिक्स एक सही चीज है। "

एक टीम थी जिसमें केवल एक एंड्रॉइड बैगन के पास आया और उसी समय छह मजबूत आईओएस डेवलपर्स। हमने असाधारण रूप से इस टीम को iOS-बग्स के साथ एक और पैकेज दिया।

इसके अलावा, क्षेत्रों के सात डेवलपर्स बैगटन के पास आए। कुछ पहली बार अपनी टीमों से मिले, जिन्हें उन्होंने पहले केवल वीडियोकांफ्रेंसिंग के जरिए देखा था। यह देखना बहुत अच्छा था कि कैसे ये लोग सक्रिय रूप से इस प्रक्रिया में शामिल हो गए।



परिणामों का मूल्यांकन कैसे किया गया?


लगभग सौ डेवलपर्स के लिए, हमारे पास केवल 15 परीक्षक थे। और रात के चार बजने वाले हैं। वे सभी पर्याप्त नहीं थे, इसलिए परीक्षण अगले दिन जारी रखा गया था। यह परीक्षक थे जिन्होंने टीमों को अंक प्रदान किए, इसलिए हमने पूर्वाग्रह को खत्म करने के लिए उन्हें टीम से निकाल दिया। एक सामान्य वर्कफ़्लो में, परीक्षक डेवलपर को कॉल कर सकता है और पता लगा सकता है: "सुनो, यार, ऐसी समस्या है ..."। बैगनॉट पर यह सख्त था: परीक्षकों को सब कुछ लपेटना चाहिए जो स्पष्ट रूप से पास नहीं होते हैं।

इसलिए हम यह देख पाए कि कुछ डेवलपर्स स्वीकृत प्रवाह में काम नहीं कर रहे हैं। हैकथॉन सभी विचलन के लिए एक प्रकार का उत्प्रेरक बन गया है। जो लोग प्रवाह में स्पष्ट रूप से काम करते हैं, वे पहली लहर में परीक्षण पारित करने और अंक प्राप्त करने में कामयाब रहे। हर कोई जो वास्तव में पत्र-व्यवहार नहीं करता था, वह कतार में आ गया, जिसे उन्होंने बैगन के बाद पहले ही रेक कर दिया था। इसमें 60 कीड़े मिले।



घटनाओं


सामान्य तौर पर, सब कुछ हमेशा की तरह चला गया, घटनाएं विशिष्ट थीं और एक कार्य क्रम में हल हो गईं। जब कुछ टूट गया, तो कुछ सिग्नलर्स ने तुरंत बगफिक्स से घटना को खत्म कर दिया।

एक मजेदार घटना थी। डैशबोर्ड तैयार करते समय, हमने संभावित जोखिमों का वर्णन किया: जीरा तक पहुंच, रोलिंग अपडेट आदि। उन्होंने सभी प्रशासकों को सूचित किया कि बैगटन के समय के लिए सभी रखरखाव कार्य, जीरा और सर्वर के अपडेट को निलंबित करना आवश्यक था। जीरा का उपयोग करने के लिए बैकअप खाते बनाए। और अचानक 18:00 के आसपास हमें पता चलता है कि डैशबोर्ड ने डेटा एकत्र करना बंद कर दिया है। मान्यताएं अलग थीं। शायद वे कुछ सुरक्षा प्रोटोकॉल को ध्यान में नहीं रखते हैं? कारण अप्रत्याशित था। हमारा संगठन बहुत बड़ा है, सभी नियोजित प्रक्रियाओं के बारे में पूरी जानकारी प्राप्त करना हमेशा संभव नहीं होता है। हमारे डैशबोर्ड को द्वितीयक सर्वरों में से एक पर वर्चुअल मशीन पर तैनात किया गया था। यह पता चला कि यह इस दिन, शुक्रवार शाम को था, कि यह सर्वर, एक अज्ञात योजना के अनुसार, आउटलेट से शारीरिक रूप से काट दिया गया था, कार में लोड किया गया और हमारे नए डेटा सेंटर में स्थायी निवास पर भेजा गया। नतीजतन, शनिवार सुबह तक हमें मैन्युअल रूप से सभी डेटा एकत्र करना था और अंकों की गणना करनी थी।

शाखाओं और अन्य परिणामों को मर्ज करें


सामान्य ऑपरेटिंग मोड में, पूरी शाखा को मैन्युअल रूप से 800+ परीक्षण मामलों द्वारा संचालित किया जाता है। परीक्षकों की एक पूरी टीम दो सप्ताह में हमारे पूर्णकालिक प्रतिगमन परीक्षण करती है। हम इतने लंबे समय तक अपरिवर्तित रखने का जोखिम नहीं उठा सकते थे। परीक्षण के समय को कम करने के लिए, हमने एप्लिकेशन के स्वास्थ्य के मुख्य परीक्षण मामलों का चयन किया - लगभग 107. सोमवार के अंत तक, उन्होंने 80% आईओएस, 50% Android और एक भी महत्वपूर्ण बग प्रकट नहीं किया। हमने तय किया कि शाखाओं का विलय किया जा सकता है।

बैगनॉट पर बंद 286 बगों में से 182 बग्स को ठीक किया गया। बाकी रेडजैक हैं जो विभिन्न कारणों, बग्स के लिए प्रासंगिक नहीं हैं (कहीं न कहीं डिजाइन या कार्यक्षमता पहले ही बदल गई है)। ये कीड़े महत्वपूर्ण नहीं हैं, लेकिन अब उन्हें विचलित होने की आवश्यकता नहीं होगी और आप शांति से महत्वपूर्ण कार्यों पर ध्यान केंद्रित कर सकते हैं।

इसके अलावा, कई, बैगन के परिणामों के बाद, एक सवाल था: हमने कितने बग बनाए? आईओएस पर केवल आठ बग और एंड्रॉइड पर सात बग।

यह हमारे लिए महत्वपूर्ण है कि डेवलपर्स टीम के अन्य सदस्यों के साथ समान आधार पर उत्पाद कोड के लिए जिम्मेदार महसूस करें। यह किसी भी विकास में महत्वपूर्ण है, लेकिन वितरित विकास में यह सफल काम के लिए एक शर्त बन जाता है। और हमारी राय में, हम उसी स्वामित्व और टीम भावना के स्तर को बढ़ाने में कामयाब रहे। परिणाम लाभ की एक गुच्छा के साथ एक कहानी थी: कुछ ही समय में हमने बग का एक गुच्छा, अनलोडेड बैकलॉग, टीम कौशल को पंप किया और बहुत सारे प्रशंसक प्राप्त किए।

Sberbank Digital Business Platform टीम द्वारा तैयार की गई सामग्री

Source: https://habr.com/ru/post/hi425835/


All Articles