CICD: बिना डाउनटाइम क्लस्टर सिस्टम वितरित करने के लिए निर्बाध तैनाती

मैं अपने पहले mitap से दूसरी रिपोर्ट पोस्ट करता हूं , जो सितंबर में आयोजित की गई थी। पिछली बार जब आप BIT.GAMES से इवान बुब्नोव से बड़े पैमाने पर राज्य सेवाओं का उपयोग करने के बारे में (और देख सकते हैं), और आज हम CICD के बारे में बात करेंगे। अधिक सटीक रूप से, हमारे सिस्टम प्रशासक Egor Panov इसके बारे में बताएंगे, जो Pixonic में बुनियादी सुविधाओं और सेवाओं की उपलब्धता के लिए जिम्मेदार हैं। कटौती के तहत - प्रदर्शन का डिकोडिंग।



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

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

1. परीक्षकों की उत्कृष्ट विशेषज्ञता;
2. उनके साथ घनिष्ठ संपर्क;
3. समय हम परीक्षण के लिए दे।

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

लेकिन CICD प्रक्रिया का निर्माण इतना सरल नहीं है। कुछ कहेंगे, ठीक है, हाँ, मैं जेनकिंस डालूँगा, मैं जल्दी से कुछ कहूँगा, अब मेरे पास CICD तैयार है। नहीं, यह केवल एक उपकरण नहीं है, यह एक अभ्यास भी है। चलिए शुरू करते हैं।


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

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

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

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

उसके बाद, उन्होंने सब कुछ फिर से लिखा, ताकि पूरी बिल्ड किसी भी TeamCity एजेंट पर हो सके और इसे Ansible पर फिर से लिखा जा सके, क्योंकि इसे Ansible पर कॉन्फ़िगर किया गया था, इसलिए तैनाती के लिए एक ही टूल का उपयोग न करें।

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

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

हम ठेस को दोहराते हुए पर्यावरण पर परीक्षण करते हैं। यह सरल है, हमने Ansible और AWX को चुना। कोई पूछ सकता है, लेकिन डॉकटर, कुबेरनेट्स, ओपनशिफ्ट के बारे में क्या है, जहां लंबे समय से बॉक्स से बाहर सभी समस्याओं का समाधान किया गया है? मैं यह कहना भूल गया कि हमारे पास लिनक्स और विंडोज दोनों के घटक हैं। और, उदाहरण के लिए, फोटॉन सर्वर, जो विंडोज पर है, हम केवल हाल ही में 10 जीबी डॉकटर कंटेनर में कम या ज्यादा पैक कर सकते हैं। तदनुसार, हमारे पास एक विंडोज एप्लिकेशन है जो कंटेनर में अच्छी तरह से पैक नहीं करता है; लिनक्स पर एक एप्लिकेशन है (जो जावा में है), जो पूरी तरह से पैक है, लेकिन इसका कोई कारण नहीं है, यह जहां भी इसे चलाता है, ठीक काम करता है। यह जावा है।

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

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


7 अंक - और हमने कुछ प्रकार की CI प्रक्रिया पहले ही बना ली है। अद्भुत। निम्नलिखित चित्र दिखाई नहीं दे रहा है, लेकिन अभी भी ग्रेवलॉग है। हैबे पर हमारे लेख कौन पढ़ता है, पहले से ही हमने देखा कि हमने कैसे ग्रेग्लॉग चुना और कैसे स्थापित किया । किसी भी मामले में, यदि कोई समस्या अभी भी हुई है, तो यह बचाव में मदद करता है।


अब इस आधार पर तैनाती के लिए आगे बढ़ना संभव है।


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

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


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

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


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

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


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

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

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


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

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


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

वास्तव में, मैं अब वहां का पालन नहीं करता जब हमारी वहां तैनाती होती है, जब रिलीज होती है। कोई "ओह, रिलीज!" महसूस नहीं हो रहा है, सब कुछ इकट्ठा हुआ और गोलगप्पे। अब यह इस तरह का एक नियमित ऑपरेशन है, मैं समय-समय पर एक चैट रूम में देखता हूं कि कुछ ठीक हो गया है। यह वास्तव में अच्छा है। जब आप ऐसा करेंगे तो आपका सिस्टम एडमिनिस्ट्रेटर खुशी से झूमेगा।

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


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

श्रोताओं से सवाल

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

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

परिनियोजन के स्वत: अद्यतन के बारे में: आप वर्तमान सर्वर में बदलाव क्यों कर रहे हैं, और एक नया नहीं जोड़ रहे हैं और सिर्फ लक्ष्य समूह या बैलेंसर में जोड़ रहे हैं?

इतनी तेजी से।

उदाहरण के लिए, यदि आपको जावा संस्करण को अपडेट करने की आवश्यकता है, तो आप अमेज़ॅन पर उदाहरण स्थिति को बदलते हैं, जावा संस्करण या कुछ और अपडेट कर रहे हैं, फिर आप उस स्थिति में कैसे रोल करते हैं? क्या आप उत्पादन सर्वर पर परिवर्तन कर रहे हैं?

हां, प्रत्येक घटक नए संस्करण और पुराने के साथ ठीक काम करता है। हां, आपको सर्वर को फिर से लोड करना पड़ सकता है।

राज्य परिवर्तन तब होते हैं जब बड़ी समस्याएं संभव हैं ...

फिर विस्फोट हो गया।

यह सिर्फ मुझे एक नया सर्वर जोड़ने के लिए लगता है और बस लक्ष्य समूह में लक्ष्य समूह पर डाल दिया जाता है - जटिलता में एक छोटा सा काम और एक बहुत अच्छा अभ्यास।

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

आप कहते हैं कि यदि हर कमिट इकट्ठा किया जाता है और यदि सब कुछ खराब है - डेवलपर सब कुछ तुरंत नियम करता है। क्या आप समझते हैं कि सब कुछ बुरा है? क्या किया जाता है?

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

यानी सबसे पहले, प्रत्येक कमिट को रोल आउट किया जाता है और परीक्षक इसे देख रहे हैं?

खैर, हर कोई नहीं, यह अभ्यास है। हमने इन 12 बिंदुओं में से एक अभ्यास किया - त्वरित। वास्तव में, यह एक लंबा और कठिन काम है, शायद वर्ष के दौरान। लेकिन आदर्श रूप से तब आप इस पर आते हैं और सब कुछ काम करता है। हां, हमें कुछ प्रकार के ऑटोटेस्ट की आवश्यकता है, कम से कम न्यूनतम सेट, कि यह सब आपके लिए काम करता है।

और सवाल छोटा है: तस्वीर में एक ऐप सर्वर है और इसी तरह, क्या मुझे इसमें रुचि है? आपने कहा था कि आपको लगता है कि डॉकर नहीं है, सर्वर क्या है? नग्न जावा या क्या?

कहीं यह विंडोज (एक गेम सर्वर) पर फोटॉन है, ऐप सर्वर टॉमकैट पर एक जावा अनुप्रयोग है।

यानी कोई virtualoks, कोई कंटेनर, कुछ नहीं?

खैर, जावा है, आप कह सकते हैं, एक कंटेनर।

और क्या यह सभी अन्सिबल के साथ रोल आउट करता है?

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

और डेटाबेस कैसे तैनात किया जाता है? घटक या सेवा पर निर्भरता?

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

क्या आपका आधार भी लोहे का है या अमेज़न में बादल में कहीं आधार है?

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

मास्टर सर्वर - यह कैसा है?

यह, वास्तव में, एक ही गेम सर्वर है, केवल मास्टर के संकेत के साथ और वह एक बैलेंसर है। यानी क्लाइंट सभी मास्टर्स को पिंग करता है, फिर वह प्राप्त करता है जिसमें से पिंग कम है, और पहले से ही मैचमेकिंग का उपयोग करने वाला मास्टर सर्वर गेम सर्वर पर कमरे एकत्र करता है और खिलाड़ी को भेजता है।

मैं सही ढंग से समझता हूं कि प्रत्येक रोलआउट के लिए आप डेटा को अपडेट करने के लिए एक माइग्रेशन लिखते हैं (यदि कोई विशेषताएँ दिखाई देती हैं)? आपने कहा कि आप पुरानी कलाकृतियों को लेते हैं और इसे भरते हैं - डेटा का क्या होता है? क्या आप आधार को रोलबैक करने के लिए माइग्रेशन लिख रहे हैं?

यह एक बहुत ही दुर्लभ रोलबैक ऑपरेशन है। हाँ, आप पेन माइग्रेशन लिखते हैं, और क्या करना है।

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

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

आप कहते हैं कि आपने अलग-अलग रिपॉजिटरी में परियोजना के अलग-अलग हिस्सों को संग्रहीत किया है, अर्थात्। क्या आपके पास किसी प्रकार की विकास प्रक्रिया है? यदि आप परियोजना को स्वयं बदलते हैं, तो आपके परीक्षण गिर जाने चाहिए क्योंकि आपने परियोजना को बदल दिया है। इसलिए जो परीक्षण अलग-अलग होते हैं, उन्हें जल्द से जल्द ठीक करने की आवश्यकता होती है।

मैंने आपको व्हेल के बारे में बताया "परीक्षकों के साथ कड़ी बातचीत।" अलग-अलग रिपॉजिटरी वाली यह योजना बहुत अच्छी तरह से काम करती है अगर कुछ बहुत ही सघन संचार हो। यह हमारे लिए कोई समस्या नहीं है, हर कोई आसानी से एक दूसरे के साथ संवाद करता है, अच्छा संचार होता है।

यानी क्या परीक्षक आपकी टीम में परीक्षण भंडार का समर्थन करते हैं? और ऑटोटेस्ट अलग से झूठ बोलते हैं?

हां। आपने कुछ विशेषता बनाई है और आप उन ऑटोटेस्ट्स को इकट्ठा कर सकते हैं जिनकी आपको परीक्षकों के भंडार से जरूरत है, और बाकी सब चीजों की जांच न करें।

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

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

आपने उत्पाद सर्वरों को ऑटोमेशन रोल आउट करने के बारे में बात की, और (जैसा कि मैं इसे समझता हूं) एक परीक्षण के लिए ऑटोमेशन रोलिंग भी है - देव वातावरण के बारे में क्या? क्या डेवलपर्स द्वारा किसी प्रकार का स्वचालन तैनात किया गया है?

लगभग यही बात। केवल एक चीज लोहे के सर्वर नहीं है, लेकिन आभासी मशीन में है, लेकिन सार उसी के बारे में है। एक ही समय में, एक ही Ansible पर, हमने लिखा (हमारे पास Ovirt है) इस आभासी मशीन का निर्माण और उस पर गाँठ।

क्या आपके पास पूरी परियोजना एक साथ एक परियोजना में संग्रहीत की जाती है Ansible prods और परीक्षण विन्यास के साथ, या क्या यह अलग से रहता है और विकसित होता है?

हम कह सकते हैं कि ये अलग प्रोजेक्ट हैं। देव (हम इसे देवबॉक्स कहते हैं) एक कहानी है जब सब कुछ एक पैक में होता है, और ठेस पर यह एक वितरित कहानी है।

Pixonic DevGAMM वार्ता के साथ अधिक वार्ता

• कंसूल का उपयोग राज्य स्तरीय सेवाओं (इवान बुबनोव, BIT.GAMES में DevOps) के लिए;
• क्वेक चैंपियंस गेम के बैकएंड प्लेटफ़ॉर्म में अभिनेता मॉडल का उपयोग करने की प्रथा (रोमन रोजोज़िन, बैकएंड डेवलपर कृपाण इंटरएक्टिव);
• टैक्टिकूल मोबाइल ऑनलाइन शूटर मेटा सर्वर आर्किटेक्चर (पावेल प्लाटो, पैंजरडॉग में लीड सॉफ्टवेयर इंजीनियर);
• कैसे ECS, C # जॉब सिस्टम और SRP आर्किटेक्चर के लिए दृष्टिकोण को बदलते हैं (वैलेंटाइन साइमनोव, फील्ड इंजीनियर एट यूनिटी);
• के विकास में KISS सिद्धांत (Konstantin Gladyshev, लीड खेल 1C खेल स्टूडियो में प्रोग्रामर);
• क्लाइंट और सर्वर पर सामान्य गेम लॉजिक (एंटोन ग्रिगोरिव, पिक्सेल में उप तकनीकी अधिकारी)।
• क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना (एंटोन कोसयाकिन, एलिस प्लेटफॉर्म पर तकनीकी उत्पाद प्रबंधक)।