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

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

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

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

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

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

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

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

एक बार, एक व्यक्ति ने Avito Android टीम में काम किया। परिभाषा के अनुसार, उन्हें कंटीन्यूअस इंटीग्रेशन से किसी चीज की जरूरत नहीं थी: इसके साथ कोई भी एकीकृत नहीं था।

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

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

चेकों

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

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

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

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

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

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

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

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

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

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

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

उसके बाद, वे आगे सोचने लगे - क्या हम इसे सही तरीके से जाँच रहे हैं? क्या हम पुल अनुरोध पर सही तरीके से निर्माण शुरू कर रहे हैं?

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

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

#!/usr/bin/env bash set -e git fetch origin develop git merge origin/develop

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

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

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

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

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

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

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

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

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

विकास को कैसे नहीं तोड़ा जाए

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

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

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

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

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

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

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

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

इस प्लगइन को लागू करने से पहले, हमारे पास प्रति पुल अनुरोध में औसतन 2.7 परीक्षण रन थे। प्लगइन के साथ 3.6 लॉन्च हुए। यह हमारे अनुकूल है।

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

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

नई जाँच

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

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

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

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

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

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

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

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

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

डॉकटर + अजगर + बैश

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

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

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

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

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

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

बेशक, हमने अपने सभी बिल्ड को गति देने का फैसला किया है।

गति बढ़ाओ

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

हम बहुत लंबी जाँच हटाते हैं

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

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

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

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

परिणामस्वरूप, हमने छोड़ दिया है:

एआरसी की विधानसभा;
जूनट परीक्षण
यंत्र परीक्षण।

रिमोट रिमोट कैश

भारी जांच के बिना, चीजें बेहतर हो गईं। लेकिन पूर्णता की कोई सीमा नहीं है!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विस्तृत प्रतिक्रिया पर छह सप्ताह खर्च किए गए।

योजनाओं

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

इसके अलावा, अन्य योजनाएं भी हैं।

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

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

टिप्स

अगर मैं केवल एक ही सलाह दे सका, तो यह होगा:

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

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

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

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

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

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

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

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

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

टिप # 2: अपने बुनियादी ढांचे को कोड में रखें।

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

लिपियों को परियोजना में संग्रहीत किया जा सकता है। और पर्यावरण के साथ क्या करना है?

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

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

यह एक साधारण docker फ़ाइल का एक उदाहरण है जिसमें 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 से तैयार कर सकते हैं) और छवि एकत्र करें, आपको एक वर्चुअल मशीन मिलती है, जिस पर आप एप्लिकेशन का निर्माण कर सकते हैं और जूनिट टेस्ट चला सकते हैं।

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

टिप नंबर 4: यह मत भूलो कि चेक चेक के लिए नहीं, बल्कि लोगों के लिए किए गए हैं।

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

टिप # 5: निरंतर एकीकरण के साथ व्यावहारिक हो।

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

टिप नंबर 6: तैयार उपकरणों का उपयोग करें।

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

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

टिप # 7: एक बड़ी टीम में, इन-हाउस समाधान अधिक लाभदायक होते हैं।

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

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

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

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

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

: 20% . , . , , , - , develop, . , , - .

Continuous Integration. .

, , AppsConf . . 22-23 .

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