हामी कसरी GitLab मा सफ्टवेयर प्याचहरू जारी गर्छौं

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

म तपाइँको स्मार्टवाचमा रिमाइन्डर सेट गर्न सिफारिस गर्दछु: प्रत्येक महिना 22 तारिखमा, GitLab मा काम गर्ने प्रयोगकर्ताहरूले हाम्रो उत्पादनको हालको संस्करणमा अद्यावधिकहरू हेर्न सक्छन्। मासिक विमोचनमा नयाँ सुविधाहरू, अवस्थितका विकासहरू समावेश छन्, र प्रायः टुलिङ वा मर्जहरूको लागि सामुदायिक अनुरोधहरूको अन्तिम परिणाम देखाउँछ।

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

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

बग वा भेद्यताको बाबजुद, gitlab.com ग्राहकहरूले तिनीहरू प्रकाशित भएको छिट्टै समाधानहरू प्राप्त गर्नेछन्, जुन स्वचालित सीडी प्रक्रियाको फाइदा हो। तिनीहरूको आफ्नै स्थापनाहरू भएका प्रयोगकर्ताहरूका लागि प्याचहरूलाई रिलीज प्रबन्धकद्वारा छुट्टै तयारी चाहिन्छ।

डेलिभरी टोलीले कम गर्न रिलीजहरू सिर्जना गर्न संलग्न अधिकांश प्रक्रियाहरूलाई स्वचालित गर्न कडा मेहनत गरिरहेको छ MTTP (उत्पादनको लागि समय, अर्थात् उत्पादनमा खर्च गरिएको समय), विकासकर्ताले gitlab.com मा डिप्लोयमेन्ट गर्नको लागि मर्ज अनुरोधलाई प्रशोधन गरेको समयको अवधि।

«डेलिभरी टोलीको लक्ष्य भनेको हामी कम्पनीको रूपमा छिटो अघि बढ्न सक्छौं, वा कम्तिमा डेलिभरी व्यक्तिहरूलाई छिटो काम गर्ने बनाउनु हो।?, मारिन भन्छन्।

दुवै gitlab.com ग्राहकहरू र तिनीहरूको स्थापनाहरूका प्रयोगकर्ताहरूले साइकल समय घटाउन र डिप्लोइमेन्टको गति बढाउन डेलिभरी टोलीको प्रयासबाट लाभ उठाउँछन्। यस लेखमा हामी यी दुई विधिहरू बीच समानता र भिन्नताहरू व्याख्या गर्नेछौं। मुद्दाहरू, र हामी हाम्रो डेलिभरी टोलीले आफ्ना सुविधाहरूमा काम गर्ने प्रयोगकर्ताहरूका लागि प्याचहरू कसरी तयार गर्छ, साथै हामी कसरी gitlab.com स्वचालित डिप्लोयमेन्ट प्रयोग गरेर अप टु डेट छ भनी सुनिश्चित गर्छौं भनेर वर्णन गर्नेछौं।

रिलीज प्रबन्धकले के गर्छ?

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

आत्म-स्थापना रिलीजहरू र gitlab.com रिलीजहरू समान कार्यप्रवाहहरू प्रयोग गर्छन् तर फरक समयमा चल्छन्, मारिन बताउँछन्।

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

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

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

यो सबै फिक्स बारे हो

प्याचहरू के हुन् र हामीलाई किन चाहिन्छ?

रिलीज प्रबन्धकले बगको गम्भीरताको आधारमा फिक्स जारी गर्ने कि नगर्ने निर्णय गर्छ।

त्रुटिहरू तिनीहरूको गम्भीरताको आधारमा भिन्न हुन्छन्। त्यसैले S4 वा S3 त्रुटिहरू शैलीगत हुन सक्छन्, जस्तै पिक्सेल वा आइकन विस्थापन। यो कम महत्त्वपूर्ण छैन, तर त्यहाँ कसैको कार्यप्रवाहमा कुनै महत्त्वपूर्ण प्रभाव छैन, जसको मतलब यस्तो S3 वा S4 त्रुटिहरूको लागि समाधान सिर्जना हुने सम्भावना सानो छ, मारिन बताउँछन्।

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

एकपटक कमजोरीहरू S1 वा S2 को लागि प्याच तयार भएपछि, रिलीज प्रबन्धकले प्याच जारी गर्न थाल्छ।

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

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

कसरी रिलीज प्रबन्धकले प्याचहरू सिर्जना गर्दछ

हामी प्याचहरू उत्पन्न गर्न GitLab CI र हाम्रो ChatOps जस्ता अन्य सुविधाहरू प्रयोग गर्छौं। रिलीज प्रबन्धकले हाम्रो आन्तरिक च्यानलमा ChatOps टोली सक्रिय गरेर फिक्सको रिलीज सुरु गर्दछ #releases स्ल्याक मा।

/chatops run release prepare 12.10.1

ChatOps ले विभिन्न घटनाहरू ट्रिगर गर्न Slack भित्र काम गर्दछ, जुन त्यसपछि GitLab द्वारा प्रशोधन र कार्यान्वयन गरिन्छ। उदाहरणका लागि, वितरण टोलीले प्याचहरू रिलिज गर्न विभिन्न चीजहरू स्वचालित गर्न ChatOps सेटअप गर्यो।

एक पटक रिलीज प्रबन्धकले Slack मा ChatOps टोली सुरु गरेपछि, बाँकी काम CICD प्रयोग गरेर GitLab मा स्वचालित रूपमा हुन्छ। रिलिज प्रबन्धकले प्रक्रियामा केही प्रमुख चरणहरू सक्रिय गर्ने हुँदा रिलिज प्रक्रियाको बखत Slack र GitLab मा ChatOps बीच दुई-तर्फी सञ्चार छ।

तलको भिडियोले 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 लाई Kubernetes-आधारित पूर्वाधारमा माइग्रेट गर्ने काम पनि गरिरहेको छ।

सम्पादकको n.b.: यदि तपाईंले Kubernetes प्रविधिको बारेमा पहिले नै सुन्नुभएको छ (र मलाई कुनै शङ्का छैन कि तपाईंसँग छ), तर अझै यसलाई आफ्नो हातले छोएको छैन भने, म अनलाइन गहन पाठ्यक्रमहरूमा भाग लिन सिफारिस गर्दछु। Kubernetes आधार, जुन सेप्टेम्बर 28-30 मा आयोजित हुनेछ, र Kubernetes मेगा, जुन अक्टोबर 14-16 सम्म हुनेछ। यसले तपाइँलाई विश्वासपूर्वक नेभिगेट गर्न र टेक्नोलोजीसँग काम गर्न अनुमति दिनेछ।

यी दुई दृष्टिकोणहरू हुन् जसले एउटै लक्ष्यलाई पछ्याउँदछ: अपडेटहरूको द्रुत डेलिभरी, दुबै gitlab.com र तिनीहरूका सुविधाहरूमा ग्राहकहरूको लागि।

हाम्रो लागि कुनै विचार वा सिफारिसहरू?

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

स्रोत: www.habr.com