मोबाइल विकास में गुणवत्ता पाइपलाइन, भाग 1: Android

^{"पाइपलाइन" के लिए अनप्लैश से फोटो}

सामान्य दृष्टिकोण

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

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

यह सब किस लिए है?

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

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

डेवलपर के कंप्यूटर पर

एक डेवलपर के रूप में, आप हमेशा अपनी मशीन पर एक IDE और कमांड लाइन टूल के साथ काम करते हैं। आइए देखें कि एंड्रॉइड डेवलपर्स के लिए क्या मौजूद है।

Android स्टूडियो

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

^{Android स्टूडियो में निरीक्षण सेटिंग्स}

AS में त्वरित सुधार भी हैं जो Alt + Enter दबाकर आपके कोड पर लागू किए जा सकते हैं।

^{एंड्रॉइड स्टूडियो से क्विक फिक्स उदाहरण}

एंड्रॉयड लिंट

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

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

^{एंड्रॉयड लिंट रिपोर्ट उदाहरण}

अधिक स्थिर विश्लेषण

बेशक, कई स्थिर विश्लेषण उपकरण हैं जो विशेष रूप से एंड्रॉइड के लिए डिज़ाइन नहीं किए गए हैं, लेकिन सामान्य रूप से जावा और कोटलिन के लिए : पीएमडी , फाइंडबग्स (छोड़े गए, स्पॉटबग्स का उपयोग करें ), चेकस्टाइल , किटलिंक , डेटेक और अन्य। अपनी पसंद के अनुसार चुनें, इसे अपनी पाइपलाइन में एकीकृत करें और इसका वास्तविक उपयोग सुनिश्चित करें (वास्तव में कैसे पढ़ें? पढ़ें)।

^{FindBugs से उदाहरण की रिपोर्ट करें}

लेकिन यह एक उपकरण के लिए पर्याप्त नहीं है जो डेटा को निश्चित करने की आवश्यकता पर प्रदान करता है। आपको निम्न जानकारी भी उपयोगी लगेगी:

1. समय के साथ परीक्षणों के साथ कोड कवरेज कैसे बदलता है?
2. मुझे मिली सभी समस्याओं को ठीक करने में कितना समय लगेगा?
3. प्रोजेक्ट में कितना डुप्लिकेट कोड है?
4. मैं अपने नियमों को कई टीमों तक कैसे बढ़ाऊं?

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

इकाई परीक्षण

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

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

एंड्रॉइड यूनिट परीक्षणों के मामले में, एक मौलिक समस्या है: एंड्रॉइड एसडीके पर निर्भरता। यह एक कारण है कि UI लेयर के ये सभी दृष्टिकोण MVP, MVVM, MVI और अन्य MV * जैसे दिखाई दिए। एंड्रॉइड पर वर्ग के आधार पर विशिष्ट समस्या यह है कि यूनिट परीक्षण केवल इस एंड्रॉइड के स्टब्स के उपयोग के कारण गिरते हैं, जो केवल एक अपवाद को फेंक देते हैं। बेशक, कुछ विकल्प हैं: या तो इस वर्ग के लिए परीक्षण छोड़ें, या कुछ तर्क को अन्य वर्गों में निकालें, या कुछ उच्च-स्तरीय तर्क का परीक्षण करने के लिए एंड्रॉइड-निर्भर कक्षाओं के लिए इंटरफेस बनाएं, या रोबोइलेक्ट्रिक (जो आदर्श से बहुत दूर है) का उपयोग करें। एक अन्य विकल्प साधन परीक्षण का उपयोग करना है, जो किसी गतिविधि के व्यवहार की जांच के लिए उपयुक्त हो सकता है, लेकिन वर्तमान प्रवृत्ति यह है कि गतिविधि में परीक्षण शामिल नहीं होने चाहिए।

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

साधन युक्त परीक्षण

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

सुरक्षा ऑडिट

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

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

सत्यापन सत्यापित करें

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

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

सीआई / सीडी पाइपलाइन

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

1. Git हुक को -no-verify विकल्प के साथ आसानी से दरकिनार किया जा सकता है
2. कोड स्थानीय रूप से सभी जांचों को सफलतापूर्वक पास कर सकता है, लेकिन मर्ज के बाद समस्याओं का परिचय दे सकता है
3. परीक्षण और कवरेज रिपोर्ट की आवश्यकता है

^{उदाहरण के लिए bitrise.io पर रिपोर्ट करें}

सौभाग्य से, आपको बस इन सुरक्षा जांचों का उल्लेख ग्रैड बिल्ड स्क्रिप्ट में सीधे करने की आवश्यकता है, या अपने CI / CD पाइपलाइन में संबंधित कार्यों का आह्वान करें। यदि आपको पाइपलाइन बनाने में कठिनाई होती है, तो मैंने हाल ही में 2019 में मोबाइल DevOps पर DevOops सम्मेलन में एक प्रस्तुति दी ।

कृपया निम्नलिखित भी करें:

1. पुल अनुरोधों के लिए सभी जांचें चलाएं। किसी भी नियम का उल्लंघन करने वाले किसी भी अनुरोध को मर्ज न करें। यह बहुत महत्वपूर्ण है: यदि नियम को निष्पादित नहीं किया जाता है, तो, वास्तव में, इसका अस्तित्व नहीं है।
2. असेंबली और परिनियोजन के दौरान सभी जाँच चलाएँ। आप अपनी गुणवत्ता पट्टी को कम नहीं करना चाहते हैं।
3. यदि निर्माण टूट गया है, तो यह पहली प्राथमिकता है। टीम को समस्या को तुरंत ठीक करना चाहिए, क्योंकि यह आपके निरंतर वितरण अभ्यास का उल्लंघन करता है और टीम को गुणवत्ता कोड लिखने से रोकता है।

और अपने कोड को बेहतर बनाने के लिए शुभकामनाएँ!

अगर आपको यह लेख पसंद आया है, तो मुझे ट्विटर पर फॉलो करें ताकि आपको निम्नलिखित याद न हो। और अगर आप दिसंबर में मास्को में होंगे या आप आ सकते हैं, तो हमारे मोबियस सम्मेलन में आएं और एंड्रॉइड (और आईओएस) के विकास के बारे में बहुत सी अन्य चीजों का पता लगाएं!

पुनश्च सिकंदर बाकानोव को प्रूफरीडिंग करने के लिए समीक्षा और टिप्पणियों के लिए अलेक्सई निकितिन से सुरक्षा के मुद्दों पर संपर्क करने के लिए विक्सेंटेल का धन्यवाद।