एकता में निरंतर एकीकरण: एक उपहार के रूप में विधानसभा के समय को कम करने और संसाधनों को बचाने के लिए + कैसे

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

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

तुरंत सहमत हूं कि हम JetBrains से TeamCity का उपयोग CI सर्वर के रूप में करते हैं, GitHub को Git रिपॉजिटरी के भंडार के रूप में, और Nexus को असेंबली कलाकृतियों को संग्रहीत करने के लिए।

इसलिए, हमने निम्नलिखित समस्याओं का सामना किया:

• एक सामान्य विधानसभा निर्माण मानक का अभाव: व्यावहारिक रूप से सभी डेवलपर्स की टीमसिटी सर्वर तक पहुंच थी, जिसके परिणामस्वरूप विधानसभा स्क्रिप्ट अलग-अलग प्रोग्रामिंग भाषाओं (BASH, PowerShell, Python) में लिखे गए थे, और तर्क को अक्सर दोहराया गया था;
• कमजोर बेड़ा: इस तथ्य के कारण कि हमें iOS के लिए बिल्ड बनाने की आवश्यकता है, हमें मैक मिनी से कारों के बेड़े का उपयोग करना था। और चूंकि एकता में लगभग पूरी विधानसभा एक धागे में होती है, इसलिए एक मशीन पर विधानसभाओं को समानांतर करना समस्याग्रस्त साबित हुआ;
• थोड़ा डिबग्ड ऑपरेशनल दक्षता: हमारे तकनीकी समर्थन की कम उत्पादकता के कारण, असेंबलियों को बहुत लंबा समय लगा;
• पर्याप्त संख्या में TeamCity एजेंटों के साथ असेंबली की प्रतीक्षा में बड़ी कतारें ;
• प्रत्येक प्रोजेक्ट के लिए एक अलग एजेंट पूल: उपकरणों पर अलग-अलग इंस्टॉल किए गए वातावरण के साथ-साथ प्रोजेक्ट्स (कैश सर्वर कॉन्फ़िगरेशन फ़ाइलों, आदि) के बीच संघर्ष करने वाली कॉन्फ़िगरेशन फ़ाइलों के कारण, एक आम पूल को व्यवस्थित करना असंभव था।

परिणामस्वरूप आपने क्या किया?

• विधानसभा लिपियों के लिए भंडार

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

• कारों का नया बेड़ा

विधानसभा समय को कम करना आवश्यक था, संभवतः उपयोग किए गए उपकरणों की संख्या को कम करना।

प्रारंभ में, हमारे पास 13 मैक मिनी कंप्यूटरों का एक खेत था, लेकिन यह समाधान इष्टतम से बहुत दूर है: एकता पर विधानसभाओं की ख़ासियत के कारण, विधानसभा समय का लगभग 80% केवल एक धागे में प्रदर्शन किया जाएगा। हार्ड ड्राइव पर लिखने की पहुंच की एक ठोस मात्रा में इसे जोड़ें और हमें लगता है कि एक मैक मिनी मुश्किल से 1-2 एक साथ असेंबली का सामना कर सकता है।

परिणाम हार्डवेयर की समीक्षा करने की आवश्यकता है।

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

यह कैसे था और क्या बन गया इसकी तुलना तालिका में दी गई है।



औसत निर्माण समय:



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

• यूनिटी के लिए बिल्डपिपलीन लाइब्रेरी

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


BuildPipeline लाइब्रेरी में विंडो को परिभाषित करता है

हमारी वर्तमान पाइपलाइन CI / CD

PullRequest विधानसभा। प्रत्येक वचन के लिए:

1. संकलन त्रुटियों की जांच करने, अद्यतन परिभाषित करने और समाधान उत्पन्न करने के लिए एकता को लॉन्च करना;
2. चल रहे परीक्षण;
3. एक स्थैतिक विश्लेषक का प्रक्षेपण: इसकी मदद से, वृद्धिशील विश्लेषण वर्तमान पुलरप्लेस्ट द्वारा प्रभावित फाइलों पर किया जाता है;
4. सत्यापन परिणाम के बारे में एक संदेश, जो GitHub पर सहेजा गया है।

एकता परियोजना का निर्माण कदम:

1. पाइथन को स्थापित करना और पायथन में निर्माण के लिए स्क्रिप्ट चलाना: हमारे सर्वर से तीसरे पक्ष के पायथन पुस्तकालयों को अपडेट करना और स्थापित करना ( pypi.org रिपॉजिटरी को प्रॉक्सी करना) और फिर बिल्ड स्क्रिप्ट चलाना।

2. एकता की विधानसभा के लिए प्रारंभिक तैयारी:

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

3. संकलन त्रुटियों के लिए जाँच करने, परिभाषित करने और समाधान उत्पन्न करने के लिए रनिंग यूनिटी।

4. परीक्षण चलाएं और यदि कोई त्रुटि हो तो उनसे बाहर निकलें - यदि आवश्यक हो।

5. आवश्यक विन्यास और अतिरिक्त परियोजना मापदंडों के साथ एकता बिल्डपिपलीन का शुभारंभ।

6. Android / iOS के लिए बनाता है - लॉन्च ग्रेड / Xcode:

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

7. संग्रहित बिल्डड्स और संबंधित फाइलों (लॉग, टेस्ट रिजल्ट, .obb, आईओएस एप्लिकेशन, dsym फाइल इत्यादि को स्थापित करने के लिए प्रकट) को आर्टिफिशियल स्टोरेज में डालने के लिए, स्टैंडअलोन असेंबली के लिए - संग्रहित संग्रह में संग्रह को अपलोड करना।

8. बिल्ड को स्थापित करने के लिए क्यूआर कोड के साथ एक पेज बनाना, Pixaauncher एप्लिकेशन के साथ आगे के काम के लिए डेटाबेस में रिपॉजिटरी और बिल्डिंग जानकारी से लिंक जोड़ना - हम इसके बारे में बाद में बात करेंगे।

9. असेंबली के परिणाम के बारे में सुस्त होने का संदेश: जिसने विधानसभा को लॉन्च किया, साथ ही साथ आवश्यक चैनलों को भी।


ऐसे मैसेज आते हैं स्लैक को

आगे के कदम

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

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

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

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


PixLauncher iOS ऐप की उपस्थिति

अंत में, अपलोडिंग स्टोर में बनाता है

प्रदर्शन किए गए सभी कार्यों के बाद, पार्टियों को आवेदन पर निर्माण और मेटा-जानकारी की गारंटी भरने की आवश्यकता स्वाभाविक रूप से होती है।

प्रारंभ में, समस्याएं ज्यादातर AppStore के साथ उत्पन्न हुईं:

• गेट में भरना केवल MacOS डिवाइस से बनाया गया है;
• आपको 25 से अधिक भाषाओं में वीडियो, स्क्रीनशॉट और एप्लिकेशन विवरण अपलोड करना होगा।

इसके कारण व्यवस्थापक पैनल में फ़ाइलों को डाउनलोड करने में भरने और क्रैश करने के लिए समय की बड़ी हानि हुई। इसलिए, हमने प्रक्रिया स्वचालन के बारे में सोचा।

परिणामस्वरूप, हमारे पास निम्नलिखित हैं:

1. Google डिस्क में, हमें सभी भाषाओं में एप्लिकेशन के विवरण के साथ एक टैबलेट मिला;
2. आवेदन के वीडियो और स्क्रीनशॉट एक निश्चित नामकरण के साथ फ़ोल्डर्स में व्यवस्थित होते हैं;
3. टीमसिटी में, पहले से ही इकट्ठे बिल्ड का चयन करने के लिए, उन्होंने रिलीज़ बिल्ड पर एक कॉन्फ़िगरेशन निर्भर किया;
4. Apple के लिए GooglePlay API और iTMSTransporter के माध्यम से, सभी आवश्यक भाषाओं के लिए स्टोर में एप्लिकेशन के बारे में बिल्ड और मेटा-जानकारी भरें। समस्याओं के मामले में (उदाहरण के लिए, एक नेटवर्क के साथ) - हम कई प्रयास करते हैं और त्रुटि पाठ के साथ स्लैक को एक संदेश भेजते हैं।

यह है कि AppStore को बिल्ड अपलोड करना कैसा दिखता है

नतीजतन - कुछ संख्या

• अब हमारे पास लगभग 400 विधानसभाएं हैं और प्रति दिन उपकरणों पर बिल्ड की 60 स्थापनाएं होती हैं;
• टीमसिटी पर 57 विभिन्न बिल्ड कॉन्फ़िगरेशन हैं;
• हम 22 टीमसिटी एजेंटों का उपयोग करते हैं, जबकि 48 एजेंटों के प्रदर्शन में महत्वपूर्ण नुकसान के बिना विस्तार करना संभव है;
• बेड़े के क्षैतिज विस्तार की संभावना है।