आज, अधिकांश सॉफ़्टवेयर उत्पाद टीमों में विकसित किए जाते हैं। सफल टीम विकास की शर्तों को एक सरल आरेख के रूप में दर्शाया जा सकता है।

एक बार जब आप अपना कोड लिख लें, तो आपको यह सुनिश्चित करना होगा:

यह काम करता है।
यह आपके सहकर्मियों द्वारा लिखे गए कोड सहित कुछ भी नहीं तोड़ता है।

यदि दोनों शर्तें पूरी होती हैं, तो आप सफलता की राह पर हैं। इन स्थितियों को आसानी से जांचने और लाभदायक पथ से विचलित न होने के लिए, हम सतत एकीकरण के साथ आए।

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

प्रिय लोग. किसी भी प्रोग्रामर का एक घंटे का काम किसी भी सर्वर के एक घंटे के काम से अधिक महंगा है।
लोग गलती करते हैं. इसलिए, ऐसी स्थितियाँ उत्पन्न हो सकती हैं जब परीक्षण गलत शाखा पर चलाए गए थे या परीक्षकों के लिए गलत कमिट संकलित की गई थी।
लोग आलसी हैं. समय-समय पर, जब मैं कोई कार्य पूरा करता हूँ, तो विचार उठता है: “जाँचने के लिए इसमें क्या है? मैंने दो पंक्तियाँ लिखीं - सब कुछ काम करता है! मुझे लगता है कि आपमें से भी कुछ लोगों के मन में कभी-कभी ऐसे विचार आते होंगे। लेकिन आपको हमेशा जांच करनी चाहिए.

निकोलाई नेस्टरोव कहते हैं कि एविटो मोबाइल डेवलपमेंट टीम में निरंतर एकीकरण को कैसे कार्यान्वित और विकसित किया गया, कैसे वे प्रति दिन 0 से 450 बिल्ड तक गए, और बिल्ड मशीनें प्रतिदिन 200 घंटे असेंबल करती थीं (nnesterov) सीआई/सीडी एंड्रॉइड एप्लिकेशन के सभी विकासवादी परिवर्तनों में भागीदार है।

कहानी एंड्रॉइड कमांड के उदाहरण पर आधारित है, लेकिन अधिकांश दृष्टिकोण आईओएस पर भी लागू होते हैं।

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

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

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

चेकों

अपनी आँखों से कोड देखना अच्छा है, लेकिन पर्याप्त नहीं। इसलिए, स्वचालित जांच शुरू की जा रही है।

सबसे पहले हम जांच करते हैं एआरके असेंबली.
बहुत जूनिट परीक्षण.
हम कोड कवरेज पर विचार करते हैं, चूँकि हम परीक्षण चला रहे हैं।

यह समझने के लिए कि ये जाँचें कैसे चलायी जानी चाहिए, आइए एविटो में विकास प्रक्रिया को देखें।

इसे इस प्रकार योजनाबद्ध रूप से दर्शाया जा सकता है:

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

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

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

यदि चेक पुल अनुरोध को रोकते हैं, तो पर्याप्त प्रेरणा होती है, क्योंकि जब तक बिल्ड हरे नहीं हो जाते, तब तक कोड विकसित नहीं होगा, जिसका अर्थ है कि कार्य पूरा नहीं होगा।

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

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

बुनियादी सीआई को पूरी तरह से स्थापित करने में हमें दो दिन लगे (इसके बाद समय का अनुमान अनुमानित है, पैमाने के लिए आवश्यक है)।

उसके बाद, हम आगे सोचने लगे - क्या हम सही ढंग से जाँच भी कर रहे हैं? क्या हम पुल अनुरोधों पर बिल्ड सही ढंग से चला रहे हैं?

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

ऐसा करने के लिए, हमने एक सरल बैश स्क्रिप्ट लिखी प्रीमर्ज.श:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

यहां विकास से सभी नवीनतम परिवर्तनों को आसानी से खींच लिया जाता है और वर्तमान शाखा में विलय कर दिया जाता है। हमने सभी बिल्ड में पहले चरण के रूप में premerge.sh स्क्रिप्ट को जोड़ा और यह जांचना शुरू किया कि हम वास्तव में क्या चाहते हैं एकीकरण.

समस्या का स्थानीयकरण करने, समाधान ढूंढने और इस स्क्रिप्ट को लिखने में तीन दिन लग गए।

एप्लिकेशन विकसित हुआ, अधिक से अधिक कार्य सामने आए, टीम बढ़ी और premerge.sh ने कभी-कभी हमें निराश करना शुरू कर दिया। डेवलप में परस्पर विरोधी परिवर्तन थे जिससे निर्माण टूट गया।

यह कैसे होता है इसका एक उदाहरण:

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

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

जब यह विकसित नहीं होने वाला है, तो यह है स्थानीय आपदा. पूरी टीम कुछ भी एकत्र करके परीक्षण के लिए प्रस्तुत नहीं कर सकती।

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

चूंकि यह हमारे अनुकूल नहीं था, इसलिए हमने इसे रोकने के विकल्प तलाशने शुरू कर दिए।

विकास कैसे न टूटे

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

यह समझने के लिए कि इसमें कितना समय लगेगा, दो पीआर के साथ एक उदाहरण पर विचार करें। हम दो पीआर खोलते हैं: दो बिल्ड, दो चेक रन। पहले पीआर के विकास में विलय के बाद, दूसरे को फिर से बनाने की जरूरत है। कुल मिलाकर, दो पीआर को तीन बार चेक की आवश्यकता होती है: 2 + 1 = 3।

सिद्धांत रूप में, यह ठीक है. लेकिन हमने आँकड़ों को देखा, और हमारी टीम में सामान्य स्थिति 10 खुले पीआर की थी, और फिर चेक की संख्या प्रगति का योग है: 10 + 9 +... + 1 = 55। यानी, 10 स्वीकार करना पीआर, आपको 55 बार पुनर्निर्माण करने की आवश्यकता है। और यह एक आदर्श स्थिति में है, जब सभी चेक पहली बार पास हो जाते हैं, जब इन दर्जनों को संसाधित करते समय कोई भी अतिरिक्त पुल अनुरोध नहीं खोलता है।

अपने आप को एक डेवलपर के रूप में कल्पना करें जिसे "मर्ज" बटन पर क्लिक करने वाला पहला व्यक्ति बनना होगा, क्योंकि यदि कोई पड़ोसी ऐसा करता है, तो आपको तब तक इंतजार करना होगा जब तक कि सभी बिल्ड फिर से न हो जाएं... नहीं, यह काम नहीं करेगा , यह गंभीर रूप से विकास को धीमा कर देगा।

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

परिणामतः तीसरा विकल्प ही शेष रह गया - बाइक. हमारे सभी कोड, हमारे सभी स्रोत Bitbucket सर्वर पर एक रिपॉजिटरी में संग्रहीत हैं। तदनुसार, हमें Bitbucket के लिए एक प्लगइन विकसित करना था।

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

परस्पर विरोधी परिवर्तनों वाले हमारे उदाहरण में, संकलन त्रुटि के कारण ऐसे निर्माण विफल हो जाएंगे। तदनुसार, फीचर बी के डेवलपर को कोड को सही करना होगा, चेक को फिर से शुरू करना होगा, फिर प्लगइन स्वचालित रूप से पुल अनुरोध लागू करेगा।

इस प्लगइन को लागू करने से पहले, हमने प्रति पुल अनुरोध पर औसतन 2,7 समीक्षा रन बनाए। प्लगइन के साथ 3,6 लॉन्च हुए। यह हमें अनुकूल लगा.

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

Bitbucket प्लगइन का पहला संस्करण लिखने में हमें दो सप्ताह लगे।

नये चेक

इस बीच, हमारी टीम बढ़ती रही। नए चेक जोड़े गए हैं.

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

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

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

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

फायरबेस टेस्ट लैब

इसे इसलिए चुना गया क्योंकि फायरबेस एक Google उत्पाद है, जिसका अर्थ है कि इसे विश्वसनीय होना चाहिए और इसके कभी खत्म होने की संभावना नहीं होनी चाहिए। कीमतें उचित हैं: एक वास्तविक डिवाइस के संचालन का $5 प्रति घंटा, एक एमुलेटर के संचालन का 1 $ प्रति घंटा।

हमारे सीआई में फायरबेस टेस्ट लैब को लागू करने में लगभग तीन सप्ताह लग गए।

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

डॉकर + पायथन + बैश

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

अपना स्वयं का परीक्षण वातावरण बनाने में पाँच सप्ताह लगे।

परिणामस्वरूप, प्रत्येक पुल अनुरोध के लिए चेक की एक व्यापक मर्ज-अवरुद्ध सूची थी:

सन्दूक विधानसभा;
जूनिट परीक्षण;
लिंट;
एंड्रॉइड स्टूडियो जाँच;
इंस्ट्रुमेंटेशन परीक्षण;
स्क्रीनशॉट परीक्षण.

इससे कई संभावित टूट-फूट को रोका जा सका। तकनीकी रूप से सब कुछ काम कर गया, लेकिन डेवलपर्स ने शिकायत की कि परिणामों के लिए प्रतीक्षा बहुत लंबी थी।

कब तक बहुत लंबा है? हमने विश्लेषण प्रणाली में बिटबकेट और टीमसिटी से डेटा अपलोड किया और इसका एहसास किया औसत प्रतीक्षा समय 45 मिनट. अर्थात्, एक डेवलपर, पुल अनुरोध खोलते समय, निर्माण परिणामों के लिए औसतन 45 मिनट तक प्रतीक्षा करता है। मेरी राय में, यह बहुत है, और आप इस तरह काम नहीं कर सकते।

निःसंदेह, हमने अपने सभी निर्माणों की गति बढ़ाने का निर्णय लिया।

आइए गति बढ़ाएं

यह देखते हुए कि बिल्ड अक्सर कतार में खड़े होते हैं, सबसे पहले हम यही करते हैं अधिक हार्डवेयर खरीदा -व्यापक विकास सबसे सरल है। बिल्ड ने कतार में लगना बंद कर दिया, लेकिन प्रतीक्षा समय केवल थोड़ा कम हुआ, क्योंकि कुछ चेकों में स्वयं बहुत लंबा समय लगा।

जिन चेकों में बहुत अधिक समय लगता है उन्हें हटाना

हमारा सतत एकीकरण इस प्रकार की त्रुटियों और समस्याओं को पकड़ सकता है।

करने के लिए नहीं जा रहा. जब परस्पर विरोधी परिवर्तनों के कारण कुछ नहीं बनता है तो सीआई एक संकलन त्रुटि पकड़ सकता है। जैसा कि मैंने पहले ही कहा, तब कोई कुछ भी इकट्ठा नहीं कर पाता, विकास रुक जाता है और हर कोई घबरा जाता है।
व्यवहार में बग. उदाहरण के लिए, जब एप्लिकेशन बनाया जाता है, लेकिन बटन दबाने पर क्रैश हो जाता है, या बटन दबाया ही नहीं जाता है। यह बुरा है क्योंकि ऐसा बग उपयोगकर्ता तक पहुंच सकता है।
लेआउट में बग. उदाहरण के लिए, एक बटन क्लिक किया गया है, लेकिन बाईं ओर 10 पिक्सेल चला गया है।
तकनीकी ऋण में वृद्धि.

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

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

परिणामस्वरूप, हमारे पास रह गए:

सन्दूक विधानसभा;
जूनिट परीक्षण;
इंस्ट्रुमेंटेशन परीक्षण.

ग्रैडल रिमोट कैश

कड़ी जाँच के बिना, सब कुछ बेहतर हो गया। लेकिन पूर्णता की कोई सीमा नहीं है!

हमारा एप्लिकेशन पहले से ही लगभग 150 ग्रेडल मॉड्यूल में विभाजित था। इस मामले में ग्रैडल रिमोट कैश आमतौर पर अच्छा काम करता है, इसलिए हमने इसे आज़माने का फैसला किया।

ग्रैडल रिमोट कैश एक ऐसी सेवा है जो अलग-अलग मॉड्यूल में व्यक्तिगत कार्यों के लिए निर्मित कलाकृतियों को कैश कर सकती है। ग्रैडल, वास्तव में कोड संकलित करने के बजाय, रिमोट कैश पर दस्तक देने के लिए HTTP का उपयोग करता है और पूछता है कि क्या किसी ने पहले ही यह कार्य किया है। यदि हाँ, तो यह बस परिणाम डाउनलोड करता है।

ग्रैडल रिमोट कैश चलाना आसान है क्योंकि ग्रैडल एक डॉकर छवि प्रदान करता है। हम इसे तीन घंटे में करने में कामयाब रहे।

आपको बस डॉकर लॉन्च करना था और प्रोजेक्ट में एक पंक्ति लिखनी थी। हालाँकि इसे जल्दी लॉन्च किया जा सकता है, लेकिन सब कुछ ठीक से काम करने में काफी समय लगेगा।

नीचे कैश मिस ग्राफ़ है।

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

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

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

पुल अनुरोध पर, हम git diff एकत्र करते हैं और संशोधित ग्रैडल मॉड्यूल ढूंढते हैं।

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

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

इंस्ट्रुमेंटेशन परीक्षणों के संचालन को उन्नत करने में ताकि वे केवल शामिल मॉड्यूल का परीक्षण कर सकें, इसमें लगभग आठ सप्ताह लग गए।

निरीक्षणों में तेजी लाने के उपाय सफलतापूर्वक काम कर रहे हैं। 45 मिनट से हम लगभग 15 मिनट तक पहुंच गए। किसी निर्माण के लिए सवा घंटे तक इंतजार करना पहले से ही सामान्य बात है।

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

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

विस्तृत फीडबैक पर छह सप्ताह व्यतीत हुए।

योजनाएं

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

इसके अलावा और भी योजनाएं हैं.

लिंट लौटें (और अन्य स्थैतिक विश्लेषण)। हम पहले से ही इस दिशा में काम कर रहे हैं.
सब कुछ पीआर अवरोधक पर चलाएँ अंत-से-अंत परीक्षण सभी SDK संस्करणों पर.

इसलिए, हमने एविटो में सतत एकीकरण के विकास के इतिहास का पता लगाया है। अब मैं अनुभवी दृष्टिकोण से कुछ सलाह देना चाहता हूँ।

Советы

यदि मैं केवल एक सलाह दे सकूं तो वह यह होगी:

कृपया शेल स्क्रिप्ट से सावधान रहें!

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

यह सब सरल स्क्रिप्ट से शुरू हुआ जो हमारी बिल्ड मशीनों पर चलती थी:

#!/usr/bin/env bash
./gradlew assembleDebug

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

आप ऐसी लिपियों के विकास में लगने वाली श्रम लागत की कल्पना कर सकते हैं। मैं आपको सलाह देता हूं कि आप इस जाल में न फंसें।

क्या बदला जा सकता है?

कोई भी स्क्रिप्टिंग भाषा. को लिखना पायथन या कोटलिन लिपि अधिक सुविधाजनक क्योंकि यह प्रोग्रामिंग है, स्क्रिप्ट नहीं।
या फॉर्म में सभी बिल्ड लॉजिक का वर्णन करें कस्टम ग्रेडेल कार्य आपके प्रोजेक्ट के लिए.

हमने दूसरा विकल्प चुनने का निर्णय लिया, और अब हम व्यवस्थित रूप से सभी बैश स्क्रिप्ट हटा रहे हैं और बहुत सारे कस्टम ग्रेडल कार्य लिख रहे हैं।

युक्ति #2: बुनियादी ढांचे को कोड में संग्रहित करें।

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

स्क्रिप्ट को किसी प्रोजेक्ट में संग्रहित किया जा सकता है. पर्यावरण का क्या करें?

युक्ति #3: डॉकर पर्यावरण में मदद कर सकता है।

यह निश्चित रूप से एंड्रॉइड डेवलपर्स को मदद करेगा; दुर्भाग्य से, iOS के पास अभी तक ऐसा नहीं है।

यह एक साधारण डॉकर फ़ाइल का उदाहरण है जिसमें jdk और android-sdk शामिल हैं:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

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

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

युक्ति संख्या 4: यह न भूलें कि निरीक्षण निरीक्षण के लिए नहीं, बल्कि लोगों के लिए किया जाता है।

डेवलपर्स के लिए त्वरित और सबसे महत्वपूर्ण, स्पष्ट प्रतिक्रिया बहुत महत्वपूर्ण है: क्या टूटा, कौन सा परीक्षण विफल रहा, मैं बिल्डलॉग कहां देख सकता हूं।

युक्ति #5: सतत एकीकरण विकसित करते समय व्यावहारिक रहें।

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

युक्ति #6: तैयार उपकरणों का उपयोग करें।

अब ऐसी कई कंपनियां हैं जो क्लाउड सीआई प्रदान करती हैं।

छोटी टीमों के लिए यह एक अच्छा समाधान है. आपको किसी भी चीज़ का समर्थन करने की ज़रूरत नहीं है, बस थोड़े से पैसे का भुगतान करें, अपना एप्लिकेशन बनाएं और यहां तक कि इंस्ट्रूमेंटेशन परीक्षण भी चलाएं।

युक्ति #7: एक बड़ी टीम में, घरेलू समाधान अधिक लाभदायक होते हैं।

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

अर्थशास्त्र सतत एकीकरण सहित हमारे संपूर्ण जीवन का वर्णन करता है। मैंने हमारे सतत एकीकरण के विकास के प्रत्येक चरण के लिए श्रम लागत का एक शेड्यूल बनाया।

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

हमने इस विचार के साथ शुरुआत की कि स्वचालन की आवश्यकता है क्योंकि लोग महंगे हैं, वे गलतियाँ करते हैं और आलसी हैं। लेकिन लोग स्वचालित भी होते हैं। इसलिए, सभी समान समस्याएं स्वचालन पर लागू होती हैं।

स्वचालन महंगा है. श्रम कार्यक्रम याद रखें.
जब स्वचालन की बात आती है, तो लोग गलतियाँ करते हैं।
कभी-कभी इसे स्वचालित करना बहुत आलसी होता है, क्योंकि सब कुछ उसी तरह से काम करता है। कुछ और क्यों सुधारें, यह सब सतत एकीकरण क्यों?

लेकिन मेरे पास आँकड़े हैं: 20% असेंबलियों में त्रुटियाँ पकड़ी जाती हैं। और ऐसा इसलिए नहीं है क्योंकि हमारे डेवलपर खराब तरीके से कोड लिखते हैं। ऐसा इसलिए है क्योंकि डेवलपर्स को भरोसा है कि अगर वे कोई गलती करते हैं, तो इसका विकास नहीं होगा, इसे स्वचालित जांच द्वारा पकड़ लिया जाएगा। तदनुसार, डेवलपर्स स्थानीय स्तर पर कुछ चलाने और परीक्षण करने के बजाय कोड और दिलचस्प चीजें लिखने में अधिक समय व्यतीत कर सकते हैं।

सतत एकीकरण का अभ्यास करें. लेकिन संयम में.

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

स्रोत: www.habr.com

मोबाइल विकास टीम में सीआई का विकास