Playrix CI / CD: हम अपने गेम का निर्माण और परीक्षण कैसे करते हैं

टीम को सुंदर और सफल गेम बनाने पर ध्यान देना चाहिए, बाकी सब के लिए CI है।

हम सीआई को कहां लागू करेंगे? हम किन दृष्टिकोणों और अवधारणाओं का उपयोग करते हैं? क्यों बनाता है और परीक्षण बनाता है? CI के बारे में विस्तृत कहानी और यह Playrix में कैसे व्यवस्थित है व्याख्यान का एक कोर्स आकर्षित करेगा। कटौती के तहत - एक संक्षिप्त निचोड़ और कुछ लहजे।


नमस्कार।

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

विचार

CI एक लक्ष्य नहीं है, यह एक उपकरण है। एक लक्ष्य होना चाहिए जिसे आप निरंतर एकीकरण के साथ प्राप्त करना चाहते हैं, एक समस्या जिसे हल करना होगा। ऐसा होता है कि एक टीम में विकास और रिहाई की प्रक्रिया "प्रार्थना और उत्पादन में" के सिद्धांत पर बनाई गई है। कभी-कभी यह उचित है, लेकिन अक्सर।

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

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

हम सीआई को कहां लागू करेंगे?

• इंजन और उपयोगिताओं,
• सभी प्लेटफार्मों के लिए हमारे खेल,
• सर्वर कोड
• विश्लेषिकी, विपणन सेवाएं, विभिन्न स्वचालन, CI सेवाएं,
• बुनियादी ढाँचा।

वह हर जगह या लगभग हर जगह है।

कंटेनर और असेंबलिंग, टेस्ट, स्टेजिंग और प्रोडक्ट, रोलिंग और कैनरी अपडेट्स में ऑटोमैटिक तैनाती - यह सब हमारे पास और सेवाओं और वेब एप्लिकेशन के लिए अधिक लागू है। आज हम खेलों के लिए CI पर ध्यान केंद्रित करेंगे: बिल्ड बिल्ड, उनका परीक्षण करें और उन्हें वितरित करें।

मानदंड

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

• कुछ दस्तावेज़ीकृत

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

ठीक है, अगर इस तरह के प्रलेखन को स्क्रिप्ट के रूप में तैयार किया गया है: मैंने एक कमांड लाइन और एक तैयार वातावरण के साथ मशीन पर मापदंडों का एक सेट दर्ज किया - मुझे एक निर्माण मिला।

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

• journaling

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

पत्रिका तब और भी उपयोगी होती है जब वह आती है, उदाहरण के लिए, सर्वर कोड के लिए। यदि कोई जानकारी नहीं है कि ठेस को किसने और कब अपडेट किया है, तो सामान्य स्थिति में यह ज्ञात नहीं है कि वर्तमान में कौन सा कोड वहां काम कर रहा है। और कभी-कभी यह बहुत महत्वपूर्ण है, बहुत।

आप इस तरह की पत्रिका को बहीखाता में रख सकते हैं, अधिमानतः एक टेबल या विकी में। CI सिस्टम में बिल्ड की सूची अनमोल है।

• सुरक्षा

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

ऐसा होता है कि सभी आवश्यक एक्सेस भंडार में संग्रहीत किए जाते हैं। एक परिकल्पना है कि यह बहुत अच्छा नहीं है। अक्सर आप "पासवर्ड दर्ज करें" फ़ील्ड देख सकते हैं, कहते हैं, जेनकिंस में, जहां बिल्ड का लेखक छिपे हुए पात्रों में प्रवेश करता है।

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

असेंबली और परिनियोजन का केंद्रीकृत प्रबंधन आपको बुनियादी ढांचे तक पहुँच अधिकारों में अंतर करने की समस्या को हल करने की अनुमति देता है। यदि आप केवल उसी बिल्ड की असेंबली तक पहुँच प्रदान कर सकते हैं जो इस सर्वर पर आवश्यक संचालन करता है, तो किसी को सर्वर तक पहुंच क्यों दें? और चूंकि एक निर्माण है, तो हमारे पास प्रलेखन और पत्रकारिता है, ठीक है, आप समझते हैं।

• पता लगाने की क्षमता

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

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

पूर्व-प्रतिबद्ध हुक

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

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

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

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

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

बिल्ड

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

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

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

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

विधानसभाओं और परीक्षणों की ऐसी आवृत्ति को उनके निष्पादन के समय को अनुकूलित करने के लिए एक विशेष दृष्टिकोण की आवश्यकता होती है।

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

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

स्टेटिक टेस्ट

असेंबली के बाद, स्थैतिक परीक्षण किया जाता है: हम फ़ोल्डर को बिल्ड के साथ लेते हैं और वहां मौजूद सभी सामग्री के चेक का एक सेट करते हैं। कोड भी सामग्री है, इसलिए इसका स्थैतिक विश्लेषण (cppcheck + PVS-Studio) भी यहाँ है।

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

रनटाइम परीक्षण

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

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

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

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

अन्य परीक्षण क्या हैं:

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

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

CATS

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

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

स्क्रिप्ट आदेशों का संपूर्ण कार्यान्वयन सार के एक सेट के पीछे छिपा हुआ है। एप्लिकेशन के साथ सहभागिता को लागू करने वाला API आपको कई तरीकों से कोई भी कार्य करने की अनुमति देता है:

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

उत्तरार्द्ध विधि उन परीक्षकों की कल्पना के लिए जगह खोलती है जो अक्सर "मुकाबला" का परीक्षण करना चाहते हैं, जहां कोई धोखा नहीं होता है। ऐसे परिदृश्यों को बनाए रखना अधिक कठिन है, लेकिन एक "मुकाबला बिल्ड" एक "मुकाबला" बिल्ड है।


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

वितरण, रिपोर्ट और निशान

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

याद रखें, आपने बिल्ड में पाई गई त्रुटियों को ठीक करने के लिए आवश्यक संसाधनों को कम करने की बात की थी? रिपोर्ट और ट्रैक - इसके बारे में:

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

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

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

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

कृषि

हम सभी प्लेटफ़ॉर्म के लिए बिल्ड इकट्ठा और टेस्ट करते हैं। इसके लिए हमें विभिन्न एजेंटों की बहुत आवश्यकता है। उन्हें मैन्युअल रूप से ट्रैक करना और बनाए रखना लंबा और कठिन है। सभी एजेंट अपने आप तैयार हो जाते हैं। हम पैकर और Ansible का उपयोग करते हैं।

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

हमने अपनी कतार अनुकूलन प्रणाली लागू की है। Teamcity में एक हमारे नंबर पर बहुत अच्छी तरह से काम नहीं करता है। संख्या की बात:

• हम हर दिन लगभग 5,000 बिल्ड इकट्ठा करते हैं। यह लगभग 500 मशीन घंटे का काम है।
• तीन करोड़ का निर्माण एक महीने पहले हुआ था।
• हमारे पास 10 विभिन्न स्थानों में 50+ बिल्ड सर्वर हैं।
• एक परीक्षण बेंच पर 40+ मोबाइल डिवाइस।
• बिल्कुल 1 Teamcity सर्वर।

सेवा के रूप में सी.आई.

Playrix CI एक सेवा है। कई परियोजनाएं हैं, कई विचार भी हैं।

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

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

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

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

सीआई कभी नहीं सोते हैं
आप देखें!