GitLab ने CI / CD और Kubernetes के लिए एक असामान्य रास्ता तय किया

हमारी डिलीवरी टीम के रूप में, केवल अपने स्वयं के संसाधनों का उपयोग करके, हमारे सिस्टम को CI / CD के तहत रिड्यूस किया।

इंजीनियरों की टीमें लगातार दबाव में हैं: आपको एक योग्य उत्पाद के रूप में नए कार्यों को देने की आवश्यकता है और साथ ही साथ समय को लगातार कम से कम करना है । अक्सर, बिना लोभी विशेषज्ञ आधुनिक उपकरणों पर कब्जा कर लेते हैं। सतत एकीकरण और वितरण (CI / CD) को हमारे एकमात्र DevOps जीवनचक्र अनुप्रयोग GitLab में बनाया गया है, और अब हम कुबेरनेट्स पर भी साइकिल का समय कम करने के लिए पलायन कर रहे हैं। हालांकि, CI / CD के लिए - और अंततः कुबेरनेट्स - हम एक असामान्य तरीके से चले गए। डिलीवरी टीम , हमें GitLab.com की निरंतर डिलीवरी पर स्विच करती है, पुरानी प्रणाली को रोकती है, और उसके बाद ही हम पूरी तरह से कुबेरनेट्स में बदल जाते हैं।

हम सीआई / सीडी से पहले रिलीज कैसे जारी करते हैं

7 अगस्त और 27 सितंबर, 2019 के बीच, विशाल गीतालाब समुदाय और हमारी टीम के सदस्य प्रति दिन औसतन 55 कमिट तक पहुंच गए - ये नए फीचर बनाने के लिए हमारे उत्पाद की निरंतर पुनरावृत्तियों हैं। लेकिन इससे पहले कि हम निरंतर वितरण में महारत हासिल करें, हमने प्रत्येक महीने की 7 तारीख से शुरू होने वाले नए कार्यों को फ्रीज़ करने की अवधि का उपयोग किया: इस समय हमारे इंजीनियरों ने नए कार्यों को विकसित करने से लेकर हर महीने की 22 तारीख को आने वाली आगामी रिलीज़ की तैयारी पर अपना ध्यान केंद्रित किया।

एक सख्त समय-सीमा शुरू करने से, हमने डेवलपर्स को एक ऐसे व्यवहार में प्रवृत्त किया जिससे उन्हें अंततः एक विशेष तारीख पर ध्यान केंद्रित करने में मदद मिली, बजाय तत्परता पर ध्यान केंद्रित करने के।

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

GitLab.com की शुरुआत के बाद से, स्थिर करने के लिए समय के रूप में नई सुविधाओं के ठंड का उपयोग किया गया है, ”मरीन ने समझाया।

हालांकि, उपयोगकर्ताओं की संख्या बढ़ रही थी और नई सुविधाओं की आवश्यकता ने हमें विकास की गति में तेजी लाने के लिए मजबूर किया। स्थिरीकरण की अवधि ने चक्र को धीमा कर दिया और डिबगिंग, प्रतिगमन और कार्यों के वितरण में परिवर्तन में देरी की - दोनों Gitlab.com और व्यक्तिगत ग्राहकों पर उपयोगकर्ताओं के लिए।

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

इससे पहले कि हम डिलीवरी टीम का गठन GitLab.com को निरंतर वितरण में स्थानांतरित करने के लिए करें - और अंततः कुबेरनेट्स के लिए - हम रिलीज मैनेजर पर निर्भर थे । यह डेवलपर्स के बीच एक संक्रमणकालीन स्थिति थी जो उस व्यक्ति के पास थी जो नई रिलीज की तैयारी कर रहा था। हम 5 साल से अधिक समय से इस प्रक्रिया की पुनरावृत्ति कर रहे हैं , लेकिन रिलीज प्रबंधकों ने एक ज्ञान का आधार बनाया है और इसे कम या ज्यादा स्वचालित बनाया है।

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

"रिलीज मैनेजर ने कार्यों की एक निश्चित सूची, एक समय सीमा प्राप्त की, और उपरोक्त चरणों को बार-बार दोहराया जब तक कि GitLab.com पर पूरी तरह से तैयार और स्थिर रिलीज प्राप्त नहीं हुई," मरीन ने कहा। सबसे सामान्य अर्थों में, रिलीज मैनेजर से निम्नलिखित की आवश्यकता थी:

• GitLab को बनाने वाली कई रिपॉजिटरी को मैन्युअल रूप से सिंक्रोनाइज़ करना।
• सुनिश्चित करें कि सही संस्करण मैन्युअल रूप से बनाई गई गिट शाखाओं में शामिल हैं।
• जब रिलीज़ टैग प्राप्त करता है, तो मैन्युअल रूप से परीक्षण और उत्पादन वातावरण को GitLab.com पर तैनात करें।
• सुनिश्चित करें कि सब कुछ काम करता है, और व्यक्तिगत उपयोगकर्ताओं के लिए मैन्युअल रूप से पैकेज प्रकाशित करें।

इस विषय के लिए समर्पित गिटलैब कमिट के दौरान ब्रुकलिन में एक प्रस्तुति में , मरीन ने 2018 के लिए टिप्पणियों के परिणामों को साझा किया: रिलीज से पहले दो सप्ताह की अवधि में, डिलीवरी टीम ने तैनाती के साथ बातचीत करते हुए 60% समय बिताया, एक अन्य 26 मैनुअल और अर्ध-मैनुअल कार्यों पर खर्च किया गया जैसे कि समीक्षा लिखना। मासिक रिलीज।

2018 के लिए अवलोकन परिणाम, निरंतर वितरण में जाने से पहले: इस तरह से डिलीवरी टीम ने रिलीज से 2 सप्ताह पहले समय बिताया।

"आम तौर पर बोलते हुए, फिर 14 दिन, रिलीज से दो हफ्ते पहले, टीम ने केवल वही किया जो मॉनिटर पर घूर रहा था, यह देख रहा था कि पेंट कैसे सूख रहा था, या कुछ और," मरीन ने कहा।

लेकिन इस पाई का 86% हिस्सा लेना (60% तैनाती के लिए + मैनुअल कार्यों के लिए 26%), डिलीवरी टीम कई समस्याओं का समाधान करेगी:

• बिना देर किए नई रिलीज।
• डाउनटाइम के बिना दोहराए जाने वाले और तेज तैनाती।
• GubLab.com को कुबेरनेट्स में स्थानांतरित करने का अधिक समय।
• निरंतर वितरण के लिए अपने संगठन को तैयार करने की अधिक स्वतंत्रता।

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

सीडी को फ्रीजिंग से संक्रमण एक समय की बात थी, क्योंकि हमारे कार्यों का ढेर बढ़ गया था, और मरीना के नेतृत्व में इंजीनियरों की एक टीम संक्रमण का निरीक्षण करती दिखाई दी: “सीडी मॉडल को कंपनी को स्थानांतरित करने के एकमात्र उद्देश्य के साथ डिलीवरी टीम का गठन किया गया था, और उसी समय कंपनी को स्थानांतरित कर दिया गया था। स्केलिंग को सुविधाजनक बनाने और साइकिल को गति देने के लिए कुबेरनेट्स मंच। "

GitLab के स्थान पर अधिकांश कंपनियों ने CI / CD और Kubernetes में संक्रमण शुरू किया, पहले नई तकनीकों को अपने वर्कफ़्लो में एकीकृत किया और प्रक्रिया में विकास प्रक्रिया को ठीक किया। हमने एक अलग दृष्टिकोण चुना है।

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

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

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

इस दृष्टिकोण ने दो प्रमुख लाभ प्रदान किए:

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

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

"जब से हमने CI / CD में महारत हासिल की, हमारे डेवलपर्स ने एक नए तरीके से समझना शुरू कर दिया कि इसका क्या मतलब है," मरीन ने कहा।

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

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

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

सीडी के साथ, आप अधिक बार कोड गुणवत्ता जांच कर सकते हैं। और जब से हमारे CI / CD सिस्टम के कोड में परिवर्तन घड़ी के चारों ओर दिए गए हैं, डेवलपर्स वास्तविक समय में आने वाली किसी भी गैर-मानक समस्याओं की मांग पर घूमते हैं, क्योंकि "ऊष्मायन अवधि" बहुत कम हो जाती है।

हमारी नई विधि

सीआई / सीडी प्रणाली को लागू करने के बाद, हमने 90% प्रक्रिया को स्वचालित कर दिया है। शेष 10% को मानव हस्तक्षेप की आवश्यकता होती है - पहुंच के अधिकार वाले कई लोगों के बीच समन्वय की आवश्यकता होती है।

"हम धीरे-धीरे इन 10% को कम कर रहे हैं - ताकि हमें प्रकाशन के प्रकाशन के लिए केवल अनुमोदन की आवश्यकता हो," मरीन ने कहा। वर्तमान पुनरावृत्ति में, CI / CD प्रक्रिया निम्नानुसार काम करती है :

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

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

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

परिणाम

GitLab पहले से ही CI / CD पर स्विच करने से बहुत लाभान्वित करता है।

2019 में टिप्पणियों और मूल्यांकन से पता चला कि रिलीज से पहले 14 दिनों में, डिलीवरी टीम 82% समय अधिक उत्पादक खर्च करती है: इसे अन्य महत्वपूर्ण कार्यों पर काम करने के लिए मुक्त किया गया था।

2019 के लिए अवलोकन से पता चला है कि 2 सप्ताह में बहुत से ऐसे कीमती समय को सीडी के लिए संक्रमण के लिए डेवलपर्स के धन्यवाद से मुक्त किया गया था।

मैन्युअल काम को स्वचालित करके, डिलीवरी टीम ने अंततः विकास गति और उपयोगकर्ता यातायात के लिए समर्थन में सुधार करने के लिए GitLab.com के बुनियादी ढांचे को बदलने के लिए स्विच किया और उसी समय, कुबेरनेट्स में प्रवास किया।

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

संक्रमण के बाद के परिणाम महत्वपूर्ण हैं। यदि मई 2019 में पुराने सिस्टम पर टीम ने कहीं 7 तैनाती प्रदान की, तो अगस्त 2019 में यह आंकड़ा बढ़कर 35 हो गया। और यह सीमा नहीं है: संख्या में काफी वृद्धि होगी - अब जब टीम रोजाना कई तैनाती प्रदान करती है।

मरीन ने कहा, "हमने अपनी रजिस्ट्री सेवा को कुबेरनेट्स में स्थानांतरित कर दिया, और यदि आप GitLab.com पर कंटेनर रजिस्ट्री का उपयोग करते हैं , तो आपके सभी अनुरोध कुबेरनेट्स प्लेटफॉर्म पर निष्पादित किए जाते हैं।" - "GitLab एक बहु-घटक प्रणाली है, और हम अन्य सेवाओं को अलग और स्थानांतरित करना जारी रखते हैं।"

प्रत्येक नई रिलीज़ में नई CI / CD विशेषताएँ शामिल हैं। उदाहरण के लिए, रिलीज़ 12.3 में, हमने GitLab कंटेनर रजिस्ट्री का विस्तार किया - उपयोगकर्ताओं को CI / CD का उपयोग करने और छवियों / टैग को अपने स्वयं के प्रोजेक्ट में इकट्ठा करने की अनुमति देता है । अन्य रोमांचक नए नवाचार थे।

निरंतर वितरण के लिए सिस्टम को भी स्थानांतरित करें?

मारिन ने उन कंपनियों को सलाह दी, जो सीडी के लिए स्विच करने वाली हैं, जो उनके पास है।

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

यदि आप इसके बारे में उत्सुक हैं, तो रोमांचक नई CI / CD विशेषताओं के इस विस्तृत सारांश पर एक नज़र डालें जो पंखों में इंतजार कर रहे हैं - रिलीज के साथ 12.4।

ब्रुकलिन GitLab प्रतिबद्ध याद किया?

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