आज, धेरैजसो सफ्टवेयर उत्पादनहरू टोलीहरूमा विकसित हुन्छन्। सफल टोली विकासको लागि सर्तहरू सरल रेखाचित्रको रूपमा प्रतिनिधित्व गर्न सकिन्छ।

एकचोटि तपाईंले आफ्नो कोड लेख्नुभएपछि, तपाईंले यसलाई सुनिश्चित गर्न आवश्यक छ:

काम गर्दछ।
यसले तपाईका सहकर्मीहरूले लेखेको कोड सहित केहि पनि तोड्दैन।

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

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

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

एभिटो मोबाइल विकास टोलीमा कसरी निरन्तर एकीकरण लागू र विकसित भयो, कसरी तिनीहरू प्रति दिन 0 देखि 450 बिल्डमा गए, र त्यो निर्माण मेसिनहरू दिनको 200 घण्टा सम्मिलित हुन्छन्, निकोलाई नेस्टेरोभ भन्छन् (nnesterov) CI/CD एन्ड्रोइड अनुप्रयोगको सबै विकासवादी परिवर्तनहरूमा एक सहभागी हो।

कथा एन्ड्रोइड कमाण्डको उदाहरणमा आधारित छ, तर अधिकांश दृष्टिकोणहरू iOS मा पनि लागू हुन्छन्।

एक पटक, एक व्यक्तिले Avito एन्ड्रोइड टोलीमा काम गरे। परिभाषा अनुसार, उसलाई निरन्तर एकीकरणबाट केहि आवश्यक पर्दैन: त्यहाँ एकीकरण गर्न कोही थिएन।

तर अनुप्रयोग बढ्यो, अधिक र अधिक नयाँ कार्यहरू देखा पर्यो, र टोली तदनुसार बढ्यो। केहि बिन्दुमा, यो अधिक औपचारिक रूपमा कोड एकीकरण प्रक्रिया स्थापना गर्ने समय हो। Git प्रवाह प्रयोग गर्ने निर्णय गरियो।

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

चेक

तपाईंको आँखाले कोड हेर्दा राम्रो छ, तर पर्याप्त छैन। त्यसकारण, स्वचालित जाँचहरू पेश गरिएको छ।

सबै भन्दा पहिले, हामी जाँच गर्छौं ARK विधानसभा.
धेरै जुनिट परीक्षणहरू.
हामी कोड कभरेज विचार गर्छौं, किनकि हामी परीक्षणहरू चलिरहेका छौं।

यी जाँचहरू कसरी चलाउनु पर्छ भनेर बुझ्नको लागि, Avito मा विकास प्रक्रिया हेरौं।

यसलाई यसरी योजनाबद्ध रूपमा प्रतिनिधित्व गर्न सकिन्छ:

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

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

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

यदि चेकहरूले पुल अनुरोधलाई रोक्छ भने, त्यहाँ पर्याप्त प्रेरणा छ, किनकि जबसम्म निर्माणहरू हरियो हुँदैन, कोड विकासमा आउँदैन, जसको मतलब कार्य पूरा हुने छैन।

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

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

आधारभूत CI पूर्ण रूपमा सेटअप गर्न हामीलाई दुई दिन लाग्यो (यसपछि समय अनुमान अनुमानित छ, स्केलको लागि आवश्यक छ)।

त्यस पछि, हामी थप सोच्न थाल्यौं - के हामी पनि सही रूपमा जाँच गर्दै हुनुहुन्छ? के हामी पुल अनुरोधहरूमा निर्माणहरू सही रूपमा चलिरहेका छौं?

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

यो गर्नको लागि, हामीले एउटा साधारण ब्यास लिपि लेख्यौं premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

यहाँ विकासबाट सबै नवीनतम परिवर्तनहरू मात्र तानिएका छन् र हालको शाखामा मर्ज गरिएका छन्। हामीले premerge.sh स्क्रिप्टलाई सबै निर्माणहरूमा पहिलो चरणको रूपमा थप्यौं र हामीले के चाहन्छौं भनेर जाँच गर्न थाल्यौं, त्यो हो। एकीकरण.

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

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

यो कसरी हुन्छ को एक उदाहरण:

दुई विकासकर्ताहरू एकैसाथ सुविधाहरू A र B मा काम गर्न थाल्छन्। सुविधा A को विकासकर्ताले परियोजनामा प्रयोग नगरिएको सुविधा पत्ता लगाउँदछ। answer() र, एक राम्रो केटा स्काउट जस्तै, यसलाई हटाउँछ। एकै समयमा, सुविधा B को विकासकर्ताले आफ्नो शाखामा यस प्रकार्यमा नयाँ कल थप्छ।

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

जब यो विकास हुन गइरहेको छैन, यो हो स्थानीय प्रकोप। सम्पूर्ण टोलीले केहि संकलन गर्न र परीक्षणको लागि पेश गर्न सक्दैन।

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

यो हामीलाई उपयुक्त नभएकोले, हामीले यसलाई कसरी रोक्ने भन्ने विकल्पहरू खोज्न थाल्यौं।

कसरी बिकास नहोस्

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

यसले कति समय लिन्छ भनेर बुझ्न, दुई PR सहितको उदाहरणलाई विचार गर्नुहोस्। हामी दुई PRs खोल्छौं: दुई निर्माण, दुई रन चेक। पहिलो पीआरलाई विकासमा मर्ज गरेपछि, दोस्रोलाई पुनर्निर्माण गर्न आवश्यक छ। कुलमा, दुई PR लाई तीन रन चेकहरू चाहिन्छ: 2 + 1 = 3।

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

आफूलाई एक विकासकर्ताको रूपमा कल्पना गर्नुहोस् जसले "मर्ज" बटनमा क्लिक गर्न पहिलो हुन आवश्यक छ, किनकि यदि छिमेकीले यो गर्छ भने, तपाईंले सबै निर्माणहरू फेरि नहुँदासम्म पर्खनुपर्नेछ... होइन, यसले काम गर्दैन। यसले विकासलाई गम्भीर रूपमा सुस्त बनाउँछ।

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

नतिजाको रूपमा, केवल तेस्रो विकल्प बाँकी - बाइक। हाम्रा सबै कोड, हाम्रा सबै स्रोतहरू बिटबकेट सर्भरमा भण्डारमा भण्डारण गरिएका छन्। तदनुसार, हामीले बिटबकेटको लागि प्लगइन विकास गर्नुपर्‍यो।

यो प्लगइनले पुल अनुरोध मर्जिङ मेकानिजमलाई ओभरराइड गर्छ। शुरुवात मानक हो: PR खुल्छ, सबै सम्मेलनहरू सुरु हुन्छन्, कोड समीक्षा पूरा भयो। तर कोड समीक्षा पूरा भएपछि र विकासकर्ताले "मर्ज" मा क्लिक गर्ने निर्णय गरेपछि, प्लगइन जाँचहरू कुन विकास राज्य विरुद्ध चेकहरू चलाइएको थियो। यदि विकास निर्माण पछि अद्यावधिक गरिएको छ भने, प्लगइनले यस्तो पुल अनुरोधलाई मुख्य शाखामा मर्ज गर्न अनुमति दिँदैन। यसले अपेक्षाकृत भर्खरको विकासको निर्माणलाई पुन: सुरु गर्नेछ।

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

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

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

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

नयाँ चेकहरू

यसबीचमा हाम्रो टोली बढ्दै गयो । नयाँ चेकहरू थपिएका छन्।

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

यो गर्नको लागि, हामीले धेरै विकृतिहरू गर्नुपर्‍यो: एन्ड्रोइड स्टुडियो लिनुहोस्, यसलाई डकरमा प्याकेज गर्नुहोस् र यसलाई भर्चुअल मनिटरको साथ सीआईमा चलाउनुहोस्, ताकि यसले वास्तविक ल्यापटपमा चलिरहेको छ भन्ने लाग्छ। तर यसले काम गर्यो।

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

तर उपकरण परीक्षण र स्क्रिनसट परीक्षणहरू उपकरणहरूमा चलाउन आवश्यक छ: इमुलेटरहरूमा वा वास्तविक उपकरणहरूमा। त्यहाँ धेरै परीक्षणहरू छन् र तिनीहरू बारम्बार चलाइएका छन् भन्ने कुरालाई ध्यानमा राख्दै, सम्पूर्ण फार्म आवश्यक छ। तपाईंको आफ्नै फार्म सुरु गर्न धेरै श्रम-गहन छ, त्यसैले हामीले एक तयार विकल्प फेला पार्‍यौं - Firebase Test Lab।

फायरबेस परीक्षण प्रयोगशाला

फायरबेस गुगल उत्पादन हो, यसको अर्थ यो भरपर्दो र कहिल्यै मर्ने सम्भावना नहुने हुनाले यो छानिएको हो। मूल्यहरू उचित छन्: $ 5 वास्तविक उपकरणको सञ्चालनको प्रति घण्टा, 1 $ प्रति घण्टा एक इमुलेटरको सञ्चालन।

हाम्रो CI मा Firebase परीक्षण प्रयोगशाला लागू गर्न लगभग तीन हप्ता लाग्यो।

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

डकर + पाइथन + ब्यास

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

यो हाम्रो आफ्नै परीक्षण वातावरण सिर्जना गर्न पाँच हप्ता लाग्यो।

नतिजाको रूपमा, प्रत्येक पुल अनुरोधको लागि चेकहरूको विस्तृत मर्ज-ब्लकिङ सूची थियो:

ARK विधानसभा;
जुनिट परीक्षण;
लिन्ट;
एन्ड्रोइड स्टुडियो जाँच;
उपकरण परीक्षण;
स्क्रिनसट परीक्षणहरू।

यसले धेरै सम्भावित ब्रेकडाउनहरू रोक्यो। प्राविधिक रूपमा सबै काम भयो, तर विकासकर्ताहरूले गुनासो गरे कि परिणामहरूको लागि पर्खाइ धेरै लामो थियो।

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

अवश्य पनि, हामीले हाम्रा सबै निर्माणहरूलाई गति दिने निर्णय गर्यौं।

छिटो गरौं

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

धेरै समय लाग्ने चेकहरू हटाउँदै

हाम्रो निरन्तर एकीकरणले यी प्रकारका त्रुटिहरू र समस्याहरू समात्न सक्छ।

जाने छैन। विरोधाभासी परिवर्तनहरूको कारणले केहि निर्माण नगर्दा CI ले संकलन त्रुटि समात्न सक्छ। मैले पहिल्यै भनेझैं, त्यसपछि कसैले केही जम्मा गर्न सक्दैन, विकास रोकिन्छ, र सबै चिन्तित हुन्छन्।
व्यवहार मा बग। उदाहरणका लागि, जब एप बनाइन्छ, तर बटन थिच्दा क्र्यास हुन्छ, वा बटन थिच्दैन। यो खराब छ किनभने यस्तो बग प्रयोगकर्तामा पुग्न सक्छ।
लेआउटमा बग। उदाहरण को लागी, एक बटन क्लिक गरिएको छ, तर बायाँ 10 पिक्सेल सारियो।
प्राविधिक ऋणमा वृद्धि.

यो सूची हेरेपछि, हामीले महसुस गर्यौं कि पहिलो दुई अंक मात्र महत्वपूर्ण छन्। हामी पहिले यस्ता समस्याहरू समात्न चाहन्छौं। लेआउटमा बगहरू डिजाइन-समीक्षा चरणमा पत्ता लगाइन्छ र त्यसपछि सजिलै सच्याउन सकिन्छ। प्राविधिक ऋणसँग व्यवहार गर्न छुट्टै प्रक्रिया र योजना चाहिन्छ, त्यसैले हामीले यसलाई पुल अनुरोधमा परीक्षण नगर्ने निर्णय गर्यौं।

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

नतिजाको रूपमा, हामीसँग बाँकी थियो:

ARK विधानसभा;
जुनिट परीक्षण;
उपकरण परीक्षण।

Gradle रिमोट क्यास

भारी जाँच बिना, सबै राम्रो भयो। तर पूर्णताको कुनै सीमा छैन!

हाम्रो अनुप्रयोग पहिले नै लगभग 150 ग्रेडल मोड्युलहरूमा विभाजित गरिएको थियो। Gradle रिमोट क्यास सामान्यतया यस अवस्थामा राम्रो काम गर्दछ, त्यसैले हामीले यसलाई प्रयास गर्ने निर्णय गर्यौं।

Gradle रिमोट क्यास एक सेवा हो जसले व्यक्तिगत मोड्युलहरूमा व्यक्तिगत कार्यहरूको लागि निर्माण कलाकृतिहरू क्यास गर्न सक्छ। Gradle, वास्तवमा कोड कम्पाइल गर्नुको सट्टा, रिमोट क्यासमा नक गर्न HTTP प्रयोग गर्दछ र सोध्नुहोस् कि कसैले यो कार्य पहिले नै गरिसकेको छ। यदि हो भने, यसले केवल परिणाम डाउनलोड गर्दछ।

Gradle रिमोट क्यास चलाउन सजिलो छ किनभने Gradle ले डकर छवि प्रदान गर्दछ। हामीले यो तीन घण्टामा गर्न सफल भयौं।

तपाईंले गर्नु पर्ने थियो डकर सुरु गर्नुहोस् र परियोजनामा एक लाइन लेख्नुहोस्। तर यो चाँडै सुरु गर्न सकिन्छ, यद्यपि सबै कुरा राम्रोसँग काम गर्न धेरै समय लाग्नेछ।

तल क्यास मिस ग्राफ छ।

सुरुमा, क्यास मिस भएको प्रतिशत लगभग 65 थियो। तीन हप्ता पछि, हामीले यो मान 20% मा बढाउन सफल भयौं। यो पत्ता लाग्यो कि एन्ड्रोइड अनुप्रयोगले सङ्कलन गर्ने कार्यहरूमा अजीब ट्रान्जिटिभ निर्भरताहरू छन्, जसको कारणले गर्दा Gradle क्यास छुटेको छ।

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

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

पुल अनुरोधमा, हामी git diff सङ्कलन गर्छौं र परिमार्जित Gradle मोड्युलहरू फेला पार्छौं।

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

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

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

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

तर अहिले विकासकर्ताहरूले कुन बिल्ड सुरु भइरहेका छन्, लग कहाँ हेर्ने, बिल्ड किन रातो छ, कुन टेस्ट फेल भयो, आदि बुझ्न नसकेको गुनासो गर्न थालेका छन् ।

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

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

योजनाहरु

पछिल्लो इतिहासमा जाऔं। प्रतिक्रिया समस्या समाधान गरिसकेपछि, हामी नयाँ स्तरमा पुग्यौं - हामीले हाम्रो आफ्नै इमुलेटर फार्म निर्माण गर्ने निर्णय गर्यौं। जब त्यहाँ धेरै परीक्षण र इमुलेटरहरू छन्, तिनीहरू व्यवस्थापन गर्न गाह्रो हुन्छन्। फलस्वरूप, हाम्रा सबै इमुलेटरहरू लचिलो स्रोत व्यवस्थापनको साथ k8s क्लस्टरमा सारियो।

साथै, अन्य योजनाहरू छन्।

लिन्ट फर्काउनुहोस् (र अन्य स्थिर विश्लेषण)। यस दिशामा हामीले पहिलेदेखि नै काम गरिरहेका छौं।
एक PR अवरोधक मा सबै चलाउनुहोस् अन्त-देखि-अन्त परीक्षणहरू सबै SDK संस्करणहरूमा।

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

Советы

यदि मैले केवल एक टुक्रा सल्लाह दिन सक्छु भने यो हुनेछ:

कृपया शेल लिपिहरूसँग सावधान रहनुहोस्!

Bash एक धेरै लचिलो र शक्तिशाली उपकरण हो, यो स्क्रिप्ट लेख्न धेरै सुविधाजनक र छिटो छ। तर तपाईं यसको साथ जालमा पर्न सक्नुहुन्छ, र, दुर्भाग्यवश, हामी यसमा पर्यौं।

यो सबै साधारण स्क्रिप्टहरूसँग सुरु भयो जुन हाम्रो निर्माण मेसिनहरूमा चल्यो:

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

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

तपाईंले त्यस्ता लिपिहरूको विकासको लागि श्रम लागतको कल्पना गर्न सक्नुहुन्छ। म तपाईलाई यो जालमा नपर्न सल्लाह दिन्छु।

के प्रतिस्थापन गर्न सकिन्छ?

कुनै पनि स्क्रिप्टिङ भाषा। मा लेख्नुहोस् पाइथन वा कोटलिन लिपि अधिक सुविधाजनक किनभने यो प्रोग्रामिङ हो, स्क्रिप्ट होइन।
वा फारममा सबै निर्माण तर्कहरू वर्णन गर्नुहोस् कस्टम ग्रेडल कार्यहरू आफ्नो परियोजना को लागी।

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

सुझाव #2: कोडमा पूर्वाधार भण्डार गर्नुहोस्।

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

स्क्रिप्टहरू परियोजनामा भण्डारण गर्न सकिन्छ। वातावरण संग के गर्ने?

टिप #3: डकरले वातावरणमा मद्दत गर्न सक्छ।

यसले पक्कै पनि एन्ड्रोइड विकासकर्ताहरूलाई मद्दत गर्नेछ; आईओएससँग अहिलेसम्म एउटा छैन, दुर्भाग्यवश।

यो 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 इन्जिनियरहरूको जीवन धेरै सजिलो बनाउँछ। एन्ड्रोइड-एसडीकेलाई डकरमा पुश गर्न एकदम सजिलो छ, तर इमुलेटरहरूसँग यो अलि बढी गाह्रो छ: तपाईंले अलि कडा मेहनत गर्नुपर्नेछ (वा GitHub बाट समाप्त भएको फेरि डाउनलोड गर्नुहोस्)।

सुझाव नम्बर 4: नबिर्सनुहोस् कि निरीक्षणहरू निरीक्षणको लागि होइन, तर मानिसहरूका लागि गरिन्छ।

द्रुत र, सबैभन्दा महत्त्वपूर्ण कुरा, स्पष्ट प्रतिक्रिया विकासकर्ताहरूको लागि धेरै महत्त्वपूर्ण छ: के ब्रेक भयो, कुन परीक्षण असफल भयो, म बिल्डलग कहाँ देख्न सक्छु।

सुझाव #5: निरन्तर एकीकरणको विकास गर्दा व्यावहारिक हुनुहोस्।

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

सुझाव #6: तयार उपकरणहरू प्रयोग गर्नुहोस्।

त्यहाँ धेरै कम्पनीहरू छन् जसले क्लाउड CI प्रदान गर्दछ।

यो साना टोलीहरूको लागि राम्रो समाधान हो। तपाईंले केहि पनि समर्थन गर्न आवश्यक पर्दैन, केवल थोरै पैसा तिर्नुहोस्, तपाईंको अनुप्रयोग निर्माण गर्नुहोस् र उपकरण परीक्षणहरू पनि चलाउनुहोस्।

सुझाव #7: ठूलो टोलीमा, इन-हाउस समाधानहरू बढी लाभदायक हुन्छन्।

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

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

यो स्पष्ट छ कि कुनै पनि सुधार अधिक र अधिक कठिन हुँदैछ। यो ग्राफ हेरेर, तपाइँ बुझ्न सक्नुहुन्छ कि निरन्तर एकीकरण टोलीको आकारको वृद्धि अनुसार विकास गर्न आवश्यक छ। दुई व्यक्तिको टोलीको लागि, आन्तरिक इमुलेटर फार्म विकास गर्न 50 दिन खर्च गर्नु एक सामान्य विचार हो। तर एकै समयमा, एक ठूलो टोलीको लागि, निरन्तर एकीकरण नगर्नु पनि नराम्रो विचार हो, किनभने एकीकरण समस्याहरू, सञ्चार फिक्सिङ, आदि। यसले अझ बढी समय लिनेछ।

हामीले स्वचालन आवश्यक छ भन्ने विचारको साथ सुरु गर्यौं किनभने मानिसहरू महँगो छन्, तिनीहरूले गल्ती गर्छन् र अल्छी छन्। तर मानिसहरू पनि स्वचालित छन्। त्यसकारण, सबै समान समस्याहरू स्वचालनमा लागू हुन्छन्।

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

तर मसँग तथ्याङ्कहरू छन्: 20% सभाहरूमा त्रुटिहरू समातिएका छन्। र यो होइन किनभने हाम्रा विकासकर्ताहरूले कोड खराब लेख्छन्। यो किनभने विकासकर्ताहरू विश्वस्त छन् कि यदि तिनीहरूले केही गल्ती गरे, यो विकासमा समाप्त हुनेछैन, यो स्वचालित जाँच द्वारा समातिनेछ। तदनुसार, विकासकर्ताहरूले स्थानीय रूपमा केहि चलाउन र परीक्षण गर्नुको सट्टा कोड र रोचक चीजहरू लेख्न बढी समय खर्च गर्न सक्छन्।

निरन्तर एकीकरण अभ्यास गर्नुहोस्। तर संयमतामा।

वैसे, Nikolai Nesterov न केवल महान रिपोर्टहरू आफैं दिन्छ, तर कार्यक्रम समितिको सदस्य पनि हो। AppsConf र अरूलाई तपाईंको लागि अर्थपूर्ण भाषणहरू तयार गर्न मद्दत गर्दछ। अर्को सम्मेलन कार्यक्रम को पूर्णता र उपयोगिता मा विषयहरु द्वारा मूल्याङ्कन गर्न सकिन्छ तालिका। र विवरणहरूको लागि, अप्रिल 22-23 मा Infospace मा आउनुहोस्।

स्रोत: www.habr.com

मोबाइल विकास टोलीमा CI को विकास

चेक