आम्ही GitLab मध्ये सॉफ्टवेअर पॅच कसे रिलीझ करतो

GitLab वर, आम्ही सॉफ्टवेअर निराकरणे दोन प्रकारे प्रक्रिया करतो: व्यक्तिचलितपणे आणि स्वयंचलितपणे. gitlab.com वर स्वयंचलित उपयोजनाद्वारे महत्त्वपूर्ण अद्यतने तयार करणे आणि वितरित करणे, तसेच वापरकर्त्यांसाठी त्यांच्या स्वतःच्या स्थापनेवर कार्य करण्यासाठी पॅचेस या रिलीझ व्यवस्थापकाच्या कार्याबद्दल जाणून घेण्यासाठी वाचा.

मी तुमच्या स्मार्टवॉचवर रिमाइंडर सेट करण्याची शिफारस करतो: दर महिन्याच्या 22 तारखेला, GitLab सह त्यांच्या सुविधांवर काम करणारे वापरकर्ते आमच्या उत्पादनाच्या वर्तमान आवृत्तीचे अपडेट पाहू शकतात. मासिक रिलीझमध्ये नवीन वैशिष्ट्ये, अस्तित्वातील विकास समाविष्ट आहेत आणि सहसा टूलिंग किंवा विलीनीकरणासाठी समुदायाच्या विनंतीचे अंतिम परिणाम दर्शविते.

परंतु, सराव दर्शविल्याप्रमाणे, सॉफ्टवेअर विकास क्वचितच दोषांशिवाय असतो. जेव्हा बग किंवा सुरक्षा भेद्यता आढळते, तेव्हा वितरण कार्यसंघातील रिलीझ व्यवस्थापक आमच्या वापरकर्त्यांसाठी त्यांच्या स्थापनेसह पॅच तयार करतो. Gitlab.com सीडी प्रक्रियेदरम्यान अपडेट केले जाते. GitLab मधील CD वैशिष्ट्यासह गोंधळ टाळण्यासाठी आम्ही या सीडी प्रक्रियेला स्वयंचलित उपयोजन म्हणतो. या प्रक्रियेमध्ये वापरकर्ते, ग्राहक आणि आमच्या अंतर्गत विकास कार्यसंघाद्वारे सबमिट केलेल्या पुल विनंत्यांच्या सूचनांचा समावेश केला जाऊ शकतो, जेणेकरून पॅचेस रिलीझ करण्याच्या कंटाळवाण्या समस्येचे निराकरण दोन भिन्न मार्गांनी केले जाईल.

«आम्ही खात्री करतो की डेव्हलपर जे काही करतात ते GitLab.com वर आणण्यापूर्वी ते दररोज सर्व वातावरणात तैनात केले जातात.", स्पष्ट करते मारिन जानकोव्हकी, वरिष्ठ तांत्रिक व्यवस्थापक, पायाभूत सुविधा विभाग. "gitlab.com डिप्लॉयमेंटसाठी स्नॅपशॉट म्हणून तुमच्या इंस्टॉलेशन्सच्या रिलीझचा विचार करा, ज्यासाठी आम्ही पॅकेज तयार करण्यासाठी स्वतंत्र पायऱ्या जोडल्या आहेत जेणेकरून आमचे वापरकर्ते त्यांच्या इंस्टॉलेशनवर इंस्टॉल करण्यासाठी ते वापरू शकतील.».

बग किंवा भेद्यतेची पर्वा न करता, gitlab.com ग्राहकांना ते प्रकाशित झाल्यानंतर लवकरच निराकरणे प्राप्त होतील, जो स्वयंचलित सीडी प्रक्रियेचा फायदा आहे. वापरकर्त्यांसाठी त्‍यांच्‍या स्‍वत:च्‍या इंस्‍टॉलेशनसह पॅचेससाठी रिलीज व्‍यवस्‍थापकाकडून वेगळी तयारी आवश्‍यक असते.

वितरण कार्यसंघ कमी करण्यासाठी रिलीझ तयार करण्यात गुंतलेल्या बहुतेक प्रक्रिया स्वयंचलित करण्यासाठी कठोर परिश्रम करत आहे MTTP (म्हणजे उत्पादनासाठी लागणारा वेळ, म्हणजे उत्पादनावर घालवलेला वेळ), विकसकाने विलीन करण्याच्या विनंतीवर प्रक्रिया करण्यापासून ते gitlab.com वर तैनात करण्यापर्यंतचा कालावधी.

«डिलिव्हरी टीमचे उद्दिष्ट हे आहे की आम्ही एक कंपनी म्हणून वेगाने पुढे जाऊ शकतो किंवा किमान डिलिव्हरी लोकांना जलद काम करू शकतो, योग्य.?, मरिन म्हणते.

gitlab.com चे ग्राहक आणि त्यांच्या इंस्टॉलेशनचे वापरकर्ते या दोघांनाही डिलिव्हरी टीमच्या सायकलच्या वेळा कमी करण्यासाठी आणि उपयोजनांना गती देण्यासाठी केलेल्या प्रयत्नांचा फायदा होतो. या लेखात आम्ही या दोन पद्धतींमधील समानता आणि फरक स्पष्ट करू. मुद्दे, आणि आम्ही आमचे वितरण कार्यसंघ त्यांच्या सुविधांवर काम करणार्‍या वापरकर्त्यांसाठी पॅच कसे तयार करतो, तसेच आम्ही स्वयंचलित उपयोजन वापरून gitlab.com अद्ययावत असल्याचे कसे सुनिश्चित करतो याचे वर्णन करू.

प्रकाशन व्यवस्थापक काय करतो?

संघ सदस्य मासिक प्रकाशन व्यवस्थापकाची भूमिका हस्तांतरित करा आमची रिलीझ वापरकर्त्यांना त्यांच्या सुविधांवरील पॅच आणि सिक्युरिटी रिलीझसह जे रिलीज दरम्यान येऊ शकतात. ते कंपनीच्या स्वयंचलित, सतत तैनातीमध्ये संक्रमणाचे नेतृत्व करण्यासाठी देखील जबाबदार आहेत.

सेल्फ-इंस्टॉलेशन रिलीझ आणि gitlab.com रिलीझ समान वर्कफ्लो वापरतात परंतु वेगवेगळ्या वेळी चालतात, मरिन स्पष्ट करतात.

सर्वप्रथम, रिलीझ मॅनेजर, रिलीझ प्रकाराकडे दुर्लक्ष करून, gitlab.com वर ऍप्लिकेशन लॉन्च केल्यापासून GitLab उपलब्ध आणि सुरक्षित असल्याची खात्री करतो, तसेच ग्राहकांच्या पायाभूत सुविधांमध्ये समान समस्या उद्भवणार नाहीत याची खात्री करून घेतो. स्वतःची क्षमता.

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 वेगवेगळ्या इव्हेंटला ट्रिगर करण्यासाठी स्लॅकमध्ये कार्य करते, ज्यावर GitLab द्वारे प्रक्रिया आणि अंमलबजावणी केली जाते. उदाहरणार्थ, डिलिव्हरी टीमने पॅच रिलीझ करण्यासाठी विविध गोष्टी स्वयंचलित करण्यासाठी ChatOps सेट केले.

एकदा रिलीझ मॅनेजरने स्लॅकमध्ये ChatOps टीम सुरू केल्यानंतर, उर्वरित काम CICD वापरून 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 ला Kubernetes-आधारित इन्फ्रास्ट्रक्चरमध्ये स्थलांतरित करण्यावर देखील काम करत आहे.

संपादकाचे एन.बी.: जर तुम्ही Kubernetes तंत्रज्ञानाबद्दल आधीच ऐकले असेल (आणि मला शंका नाही की तुमच्याकडे आहे), परंतु अद्याप ते तुमच्या हातांनी स्पर्श केले नाही, तर मी ऑनलाइन गहन अभ्यासक्रमांमध्ये भाग घेण्याची शिफारस करतो. कुबर्नेट्स बेस, जे सप्टेंबर 28-30 आयोजित केले जाईल, आणि Kubernetes मेगा, जे 14-16 ऑक्टोबर रोजी होईल. हे आपल्याला आत्मविश्वासाने नेव्हिगेट करण्यास आणि तंत्रज्ञानासह कार्य करण्यास अनुमती देईल.

हे दोन दृष्टीकोन आहेत जे समान ध्येयाचा पाठपुरावा करतात: gitlab.com आणि ग्राहकांसाठी त्यांच्या सुविधांवरील अद्यतनांचे जलद वितरण.

आमच्यासाठी काही कल्पना किंवा शिफारसी?

GitLab मध्ये योगदान देण्यासाठी प्रत्येकाचे स्वागत आहे आणि आम्ही आमच्या वाचकांच्या अभिप्रायाचे स्वागत करतो. तुमच्याकडे आमच्या वितरण कार्यसंघासाठी काही कल्पना असल्यास, अजिबात संकोच करू नका एक विनंती तयार करा सूचना सह team: Delivery.

स्त्रोत: www.habr.com