हम GitLab में सॉफ़्टवेयर पैच कैसे जारी करते हैं

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

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

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

«हम यह सुनिश्चित करते हैं कि डेवलपर्स जो कुछ भी बनाते हैं उसे GitLab.com पर रोल आउट करने से पहले हर दिन सभी परिवेशों में तैनात किया जाता है", समझाता है मारिन जांकोवकी, वरिष्ठ तकनीकी प्रबंधक, इंफ्रास्ट्रक्चर विभाग। "अपने इंस्टॉलेशन के लिए रिलीज़ को gitlab.com परिनियोजन के स्नैपशॉट के रूप में सोचें, जिसके लिए हमने एक पैकेज बनाने के लिए अलग-अलग चरण जोड़े हैं ताकि हमारे उपयोगकर्ता अपने इंस्टॉलेशन पर इंस्टॉल करने के लिए इसका उपयोग कर सकें।'.

बग या भेद्यता के बावजूद, gitlab.com ग्राहकों को प्रकाशित होने के तुरंत बाद सुधार प्राप्त होंगे, जो स्वचालित सीडी प्रक्रिया का एक लाभ है। अपने स्वयं के इंस्टॉलेशन वाले उपयोगकर्ताओं के लिए पैच को रिलीज़ प्रबंधक द्वारा अलग से तैयारी की आवश्यकता होती है।

डिलीवरी टीम रिलीज़ को कम करने में शामिल अधिकांश प्रक्रियाओं को स्वचालित करने के लिए कड़ी मेहनत कर रही है एमटीटीपी (उत्पादन के लिए औसत समय, यानी उत्पादन पर खर्च किया गया समय), डेवलपर द्वारा मर्ज अनुरोध को संसाधित करने से लेकर gitlab.com पर तैनाती तक की समय अवधि।

«डिलीवरी टीम का लक्ष्य यह सुनिश्चित करना है कि हम एक कंपनी के रूप में तेजी से आगे बढ़ सकें, या कम से कम डिलीवरी करने वालों को तेजी से काम करने लायक बनाएं, ठीक है?, मैरिन कहते हैं।

चक्र समय को कम करने और तैनाती में तेजी लाने के लिए डिलीवरी टीम के प्रयासों से gitlab.com के ग्राहक और उनके इंस्टॉलेशन के उपयोगकर्ता दोनों लाभान्वित होते हैं। इस लेख में हम इन दोनों तरीकों के बीच समानताएं और अंतर बताएंगे। मुद्दे, और हम यह भी बताएंगे कि हमारी डिलीवरी टीम अपनी सुविधाओं पर काम करने वाले उपयोगकर्ताओं के लिए पैच कैसे तैयार करती है, साथ ही हम यह कैसे सुनिश्चित करते हैं कि gitlab.com स्वचालित तैनाती का उपयोग करके अद्यतित है।

एक रिलीज़ प्रबंधक क्या करता है?

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

सेल्फ-इंस्टॉलेशन रिलीज़ और gitlab.com रिलीज़ समान वर्कफ़्लो का उपयोग करते हैं लेकिन अलग-अलग समय पर चलते हैं, मैरिन बताते हैं।

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

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

रिलीज़ मैनेजर को यह तय करना होगा कि फ़िक्स तैयार करना है या इसे कब तैनात करना है - और यह स्थिति के संदर्भ पर अत्यधिक निर्भर है, "इस बीच, मशीनें लोगों की तरह संदर्भ प्रबंधन में उतनी अच्छी नहीं हैं"मारिन कहते हैं.

यह सब सुधारों के बारे में है

पैच क्या हैं और हमें उनकी आवश्यकता क्यों है?

रिलीज़ मैनेजर बग की गंभीरता के आधार पर निर्णय लेता है कि फिक्स जारी करना है या नहीं।

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

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

एक बार कमजोरियों S1 या S2 के लिए पैच तैयार हो जाने पर, रिलीज़ मैनेजर पैच जारी करना शुरू कर देता है।

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

जब बहुत सारे S4, S3 और S2 जमा हो जाते हैं, तो रिलीज़ मैनेजर किसी फिक्स को रिलीज़ करने की तात्कालिकता निर्धारित करने के लिए संदर्भ को देखता है, और जब उनकी एक निश्चित संख्या तक पहुँच जाती है, तो वे सभी संयुक्त और रिलीज़ हो जाते हैं। रिलीज़ के बाद के सुधारों या सुरक्षा अद्यतनों को ब्लॉग पोस्ट में संक्षेपित किया गया है।

एक रिलीज़ प्रबंधक पैच कैसे बनाता है

हम पैच बनाने के लिए GitLab CI और हमारे ChatOps जैसी अन्य सुविधाओं का उपयोग करते हैं। रिलीज़ मैनेजर हमारे आंतरिक चैनल पर चैटऑप्स टीम को सक्रिय करके फिक्स की रिलीज़ शुरू करता है #releases स्लैक में.

/chatops run release prepare 12.10.1

चैटऑप्स विभिन्न घटनाओं को ट्रिगर करने के लिए स्लैक के भीतर काम करता है, जिसे बाद में GitLab द्वारा संसाधित और निष्पादित किया जाता है। उदाहरण के लिए, डिलीवरी टीम ने पैच जारी करने के लिए विभिन्न चीजों को स्वचालित करने के लिए ChatOps की स्थापना की।

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

नीचे दिया गया वीडियो GitLab के लिए पैच तैयार करने की तकनीकी प्रक्रिया दिखाता है।

gitlab.com पर स्वचालित परिनियोजन कैसे कार्य करता है

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

ChatOps का उपयोग करके परिनियोजन चलाने के बजाय, हम CI सुविधाओं का उपयोग करते हैं जैसे। अनुसूचित पाइपलाइन, जिसके साथ रिलीज मैनेजर आवश्यक समय पर किए जाने वाले कुछ कार्यों को शेड्यूल कर सकता है। मैन्युअल प्रक्रिया के बजाय, एक पाइपलाइन है जो समय-समय पर एक घंटे में एक बार चलती है जो GitLab परियोजनाओं में किए गए नए परिवर्तनों को डाउनलोड करती है, उन्हें पैकेज करती है और तैनाती को शेड्यूल करती है, और स्वचालित रूप से परीक्षण, QA और अन्य आवश्यक चरण चलाती है।

मैरिन कहते हैं, "इसलिए हमारे पास gitlab.com से पहले विभिन्न वातावरणों में बहुत सारी तैनाती चल रही हैं, और उन वातावरणों के अच्छी स्थिति में होने और परीक्षण के अच्छे परिणाम दिखाने के बाद, रिलीज़ मैनेजर gitlab.com परिनियोजन क्रियाएं शुरू करता है।"

gitlab.com अपडेट का समर्थन करने के लिए CICD तकनीक पूरी प्रक्रिया को उस बिंदु तक स्वचालित कर देती है, जहां रिलीज मैनेजर को gitlab.com पर उत्पादन वातावरण की तैनाती को मैन्युअल रूप से लॉन्च करना होगा।

मारिन नीचे दिए गए वीडियो में gitlab.com अपडेट प्रक्रिया के बारे में विस्तार से बताती हैं।

डिलीवरी टीम और क्या करती है?

gitlab.com अपडेट प्रक्रियाओं और इन-हाउस ग्राहकों के लिए पैच जारी करने के बीच मुख्य अंतर यह है कि बाद की प्रक्रिया के लिए रिलीज़ मैनेजर से अधिक समय और अधिक मैन्युअल काम की आवश्यकता होती है।

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

डिलीवरी टीम के अल्पकालिक लक्ष्यों में से एक रिलीज को गति देने के लिए रिलीज मैनेजर की ओर से मैन्युअल काम की मात्रा को कम करना है। टीम रिलीज़ प्रक्रिया को सरल बनाने, सुव्यवस्थित करने और स्वचालित करने के लिए काम कर रही है, जिससे कम गंभीरता वाली समस्याओं (S3 और S4) को ठीक करने में मदद मिलेगी। लगभग। अनुवादक). गति पर ध्यान केंद्रित करना एक प्रमुख प्रदर्शन संकेतक है: MTTP को कम करना आवश्यक है - मर्ज अनुरोध प्राप्त करने से लेकर gitlab.com पर परिणाम तैनात करने तक का समय - वर्तमान 50 घंटे से 8 घंटे तक।

डिलीवरी टीम gitlab.com को कुबेरनेट्स-आधारित बुनियादी ढांचे में स्थानांतरित करने पर भी काम कर रही है।

संपादक का एनबी: यदि आपने पहले से ही कुबेरनेट्स तकनीक के बारे में सुना है (और मुझे इसमें कोई संदेह नहीं है कि आपके पास है), लेकिन अभी तक इसे अपने हाथों से नहीं छुआ है, तो मैं ऑनलाइन गहन पाठ्यक्रमों में भाग लेने की सलाह देता हूं कुबेरनेट्स बेस, जो 28-30 सितंबर को आयोजित किया जाएगा, और कुबेरनेट्स मेगा, जो 14-16 अक्टूबर को होगा। यह आपको आत्मविश्वास से नेविगेट करने और प्रौद्योगिकी के साथ काम करने की अनुमति देगा।

ये दो दृष्टिकोण हैं जो एक ही लक्ष्य का पीछा करते हैं: gitlab.com और उनकी सुविधाओं पर ग्राहकों दोनों के लिए अपडेट की तेज़ डिलीवरी।

हमारे लिए कोई विचार या सिफ़ारिशें?

GitLab में योगदान देने के लिए सभी का स्वागत है, और हम अपने पाठकों से प्रतिक्रिया का स्वागत करते हैं। यदि आपके पास हमारी डिलीवरी टीम के लिए कोई विचार है, तो संकोच न करें एक अनुरोध बनाएँ चिह्नित team: Delivery.

स्रोत: www.habr.com