🥔 🤴 🔢 ओपन सोर्स: एंड्रॉइड के लिए CI / CD और Avito टेस्ट इन्फ्रास्ट्रक्चर 🚄 ⚫️ 🖥️

हमने एंड्रॉइड ओपन सोर्स इन्फ्रास्ट्रक्चर के लिए एविटो को स्थानांतरित किया: ग्रैडल प्लगइन्स, एमुलेटर और टेस्ट लाइब्रेरी। हमारा कोड CI / CD को स्वचालित करने में उपयोगी होगा, और ऑटोटेस्ट के लेखन और समर्थन को भी सुविधाजनक बनाएगा।

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

हम कौन हैं, और क्या करते हैं

हम स्पीड प्लेटफॉर्म टीम में एंड्रॉइड इंडस्ट्री पर काम कर रहे हैं। हम में से चार हैं:

सरोजोहा बिश्तियन
वरिष्ठ इंजीनियर
ट्विटर अकाउंट

Dima Voronin
लीड इंजीनियर
ट्विटर अकाउंट

जेन्या क्रिवोबोकोव
वरिष्ठ इंजीनियर
ट्विटर अकाउंट

डेनियल पोपोव
वरिष्ठ इंजीनियर
ट्विटर अकाउंट

हम तेजी से उपयोगकर्ताओं को सभी Avito Android अनुप्रयोगों में परिवर्तन प्रदान करने के लिए जिम्मेदार हैं। जिम्मेदारी के हमारे क्षेत्र में शामिल हैं:

परियोजना के साथ स्थानीय कार्य: ताकि सब कुछ जल्दी से इकट्ठा हो और आईडीई धीमा न हो।
सीआई पाइपलाइन: परीक्षण, सभी संभव जांच।
सीडी: रिलीज इंजीनियरों के लिए उपकरण।

हमें खुले स्रोत की आवश्यकता क्यों है

हम सिर्फ जीथब पर खुले भंडार में कोड को मिरर नहीं करना चाहते थे, बल्कि इसे अपने और इंजीनियरिंग समुदाय के लाभ के लिए करना चाहते थे। स्रोत को खोलने के लिए परियोजना को लेने के मुख्य कारण पाँच हैं:

प्रतिक्रिया हासिल करें।
उद्योग के मानकों को प्रभावित करना।
नई चीज़ें सीखें।
तृतीय-पक्ष पुस्तकालयों को प्रभावित करें।
अपने व्यक्तिगत ब्रांड को बढ़ावा दें।

आइए संक्षेप में उन पर चलते हैं।

प्रतिक्रिया प्राप्त करें और पुन: उपयोग के लिए कोड को आसान बनाएं

हम Avito इंजीनियरों के लिए ट्यूनिंग बनाते हैं, और हमारे उपयोगकर्ताओं को बस काम करने के लिए सभी समाधानों की आवश्यकता होती है। हमारे पास उन डेवलपर्स से दृश्य की कमी है जो समान समस्याओं को हल करते हैं। यदि वे आंतरिक कार्यान्वयन और हमारी परियोजना से जुड़ने की सुविधा की समस्याओं को इंगित करते हैं तो यह अच्छा होगा।

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

उद्योग के मानकों को प्रभावित करना

हम 2017 से मोबाइल एप्लिकेशन के लिए बुनियादी ढांचे का विकास कर रहे हैं और नियमित रूप से सम्मेलनों और बैठकों में इसके बारे में बात करते हैं:

एलेक्सी Shpirko "मोबाइल एप्लिकेशन Avito में जारी करता है" - मोबियस 2018 पाइटर ।
दिमित्री मर्करीव प्रभाव विश्लेषण - AppsConf: QualityApps 2018।
निकोले नेस्टरोव "मोबाइल विकास टीम में सीआई का विकास" - सेंट एप्सकॉन्फ 2018।
एलेक्सी में एलेक्सी शापिरको "ऑटो परीक्षण। वे क्यों करते हैं, वे कैसे मदद करते हैं, उनकी लागत कितनी है ” - एप्स मॉस्को 2019।
एव्जेनी क्रिवोबोकोव "एक मल्टी-मॉड्यूल एंड्रॉइड एप्लिकेशन की असेंबली को तेज कर रहा है" - ऐप्स कॉन्फ मॉस्को 2019।

कहानियों के अलावा, हम हमेशा कोड को साझा करना चाहते थे और इसे पुन: उपयोग करने का अवसर देते थे। दरअसल, कई Android डेवलपर्स समान चुनौतियों का सामना करते हैं:

ऑटोटेस्ट कैसे लिखें ताकि उन्हें लाभ हो।
उन्हें पुल अनुरोधों में कैसे चलाना है।
इंफ्रास्ट्रक्चर बनाए रखने के लिए कैसे सस्ता होगा।

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

दूसरों को समझाकर सीखें

सिर्फ खुले स्रोत में कोड डालना पर्याप्त नहीं है। अभ्यास, दृष्टिकोण, समस्याओं को खोजने और निर्णय लेने के तरीके महत्वपूर्ण हैं। उन्हें दिखाते हुए, हम जांचते हैं कि हमारे विचार और तैयार-किए गए प्रस्ताव Avito के बाहर कैसे काम करते हैं।

तृतीय-पक्ष लाइब्रेरीज़ को प्रभावित करें और उनकी समस्याओं को तेज़ी से ठीक करें

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

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

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

पीआर और व्यक्तिगत प्रेरणा

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

ओपन सोर्स के लिए क्या लाया गया था

हमने अपने लगभग सभी Android और CI / CD टेस्टिंग इन्फ्रास्ट्रक्चर को Github रिपॉजिटरी में डाल दिया । अन्य डेवलपर्स के लिए प्रोजेक्ट को नेविगेट करना आसान बनाने के लिए, सभी मॉड्यूल उद्देश्य से समूहीकृत हैं:

मैं सबसे महत्वपूर्ण पुस्तकालयों के एक जोड़े पर ध्यान दूंगा।

टेस्ट रनर

यह इंस्ट्रूमेंटेशन टेस्ट चलाने के लिए एक वर्गीकृत प्लगइन है। निकटतम एनालॉग मैराथन है , लेकिन हमारा केवल एंड्रॉइड के लिए लिखा गया है।

टेस्ट रनर:

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

परिणाम कस्टम टीएमएस (परीक्षण प्रबंधन प्रणाली) में संग्रहीत किए जाते हैं, यह खुले स्रोत में नहीं है। हम एक और कार्यान्वयन को जोड़ने की संभावना पर काम कर रहे हैं।

प्रभाव का विश्लेषण

हमारे पास लगभग 1600 इंस्ट्रूमेंटेशन टेस्ट और 10K यूनिट टेस्ट हैं। हम किसी भी कोड परिवर्तन के लिए सभी परीक्षण चलाना चाहते हैं, लेकिन यह संभव नहीं है - रन में बहुत अधिक समय लगेगा।

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

हमने एक ग्रैडल प्लगइन लिखा था जो मॉड्यूल, पार्स परीक्षणों में परिवर्तन की तलाश करता है और यह निर्धारित करता है कि किन लोगों को चलाना है।

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

हमारे पुस्तकालय कैसे उपयोगी हो सकते हैं

चूंकि परियोजना में कई घटक हैं, इसलिए इसका उपयोग आपकी आवश्यकताओं पर निर्भर करता है। यदि आप एक ऐसी ही समस्या का समाधान कर रहे हैं या सिर्फ तकनीक को समझना चाहते हैं, तो बेझिझक हमें टेलीग्राम चैट में रूसी या अंग्रेजी में लिखें । हम आपको बताएंगे कि हम क्या जानते हैं, प्रासंगिक उदाहरणों की मदद करने और दिखाने की कोशिश करते हैं।

आप कुछ भी पूछ सकते हैं:

आप अस्थिर परीक्षणों के साथ कैसे काम करते हैं?
इतना कोड क्यों? वह बेकार है।
क्यों ग्रेड प्लगइन्स में सभी कोड है, पायथन लिपियों में नहीं?

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

दुर्भाग्य से, हमारे पास अभी भी अन्य परियोजनाओं में पुन: उपयोग के कुछ उदाहरण हैं, इसलिए एकीकरण अभी भी अज्ञात प्रतिबंधों को प्रकट कर सकता है। अगर ऐसा होता है, तो हमें लिखें और हम देखेंगे कि अंतिम रूप देने की क्या आवश्यकता है।

निष्कर्ष

निम्नलिखित लेखों में हम इस बारे में बात करने की योजना बनाते हैं:

हमारे परीक्षण धावक।
परीक्षण का एनाटॉमी - परिणाम प्राप्त करने के लिए आईडीई में "रन" बटन दबाने से क्या होता है।
हम परीक्षण और बुनियादी ढांचे की अस्थिरता के साथ कैसे संघर्ष करते हैं।
बुनियादी ढांचे को लिखने के लिए हमारा दृष्टिकोण।
हमने महीने से सप्ताह के लिए रिलीज़ का समय कम कर दिया है।

अधिक सामान्य विषयों पर विचार हैं:

परीक्षण लिखना कैसे शुरू करें
शुरुआती के लिए परीक्षण के बुनियादी ढांचे - सामान्य दृष्टिकोण और प्रौद्योगिकियों के बारे में।

हमें टिप्पणियों में बताएं कि आपको क्या जानने की दिलचस्पी होगी। तो हम समझेंगे कि कौन सा पाठ पहले लिखना है।

ओपन सोर्स: एंड्रॉइड के लिए CI / CD और Avito टेस्ट इन्फ्रास्ट्रक्चर