GitLab में कोड संग्रहण की व्यवस्था करना और GitFlow में कोड समीक्षा को एकीकृत करना

इतना समय पहले नहीं, हमारी कंपनी के एक प्रोजेक्ट में, अंततः Git के पक्ष में कोडिंग और वर्जनिंग कोड के लिए सबवर्सन के उपयोग को छोड़ने का निर्णय लिया गया था।

संक्रमण के मुख्य उद्देश्य इस प्रकार थे:

• विकास प्रक्रिया की पारदर्शिता में सुधार।
• परीक्षण वातावरण को अद्यतन करने से पहले अनिवार्य कोड समीक्षा प्रक्रिया का कार्यान्वयन।
• कोड समीक्षा के बाद अपडेट बनाने और परीक्षण वातावरण पर उन्हें स्थापित करने के लिए निरंतर एकीकरण को लागू करें।

इन लक्ष्यों को प्राप्त करने के लिए एक शर्त GitLab का उपयोग था (यह गिट सर्वर पहले से ही ग्राहक द्वारा उपयोग किया गया था और वहां पहले से ही कोड था जो समाधान के मोर्चे से संबंधित था) और जीरा (पहले से ही ग्राहक द्वारा उपयोग किया जाता है)।

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

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

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

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

स्रोत कोड को संग्रहीत करने के लिए बनाई गई रिपॉजिटरी को स्थानीय रिपॉजिटरी (git क्लोन) में अपलोड किया जाता है और Git Flow (git flow init) को इसमें आरम्भ किया जाता है - मास्टर ब्रांच के अलावा (स्थिर टैग स्टोर करने के लिए टैग बनाने के लिए, डेवलपमेंट ब्रांच बनाया जाता है (मुख्य विकास शाखा, में) जो फ़ंक्शन शाखाओं, रिलीज़ और फ़िक्सेस को एकीकृत करता है), फ़ंक्शन शाखाओं के लिए मास्क, रिलीज़ और फ़िक्सेस सेट किए जाते हैं, और विकसित शाखा के लिए एक संक्रमण भी बनाया जाता है।

इसके बाद, सबवर्सन से वर्तमान स्रोत कोड शाखा को काम करने वाली कॉपी में स्थानांतरित कर दिया जाता है, स्थानीय रिपॉजिटरी की शाखा को विकसित करने और रिमोट रिपॉजिटरी (जीआईटी पुश ओरिजिनल डेवलपमेंट) पर अपलोड करने के लिए कोड प्रतिबद्ध है (git add -A + git कमिट-एम "कमिट मैसेज")। उसके बाद, आप कोड को संस्करणित करने के लिए Git का उपयोग करके नई कार्यक्षमता विकसित करना शुरू कर सकते हैं।

विकास के दौरान, विकसित शाखा का वर्तमान संस्करण डाउनलोड किया जाता है और नए कार्यों के विकास के लिए इसमें से शाखाएं बनाई जाती हैं (जीआट फ्लो सुविधा शुरू MYFEATURE) जिरा टास्क कोड के अनुसार जिसमें विकास किया जा रहा है।

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

जब चयनित कार्य की कार्यक्षमता विकसित की जाती है और परीक्षण वातावरण में प्रस्तुत करने के लिए तैयार होती है, तो बनाए गए कमिट्स को रिमोट ब्रांच पर उसी नाम (git push -u Origin MYFEATURE) के साथ अपलोड किया जाता है और डाउनलोड की गई शाखा को मर्ज करने के लिए अनुरोध करने के लिए टीम लीड या उसके अभिनय कर्तव्यों के लिए बनाया जाता है।

मर्ज करने का अनुरोध करने के लिए, डेवलपर मर्ज विरोधों (यदि कोई हो) और विकास टीम लीड (या अभिनय) को हल करता है एक कोड समीक्षा का उत्पादन करता है, जिसके दौरान टिप्पणियों के सुधार के साथ अतिरिक्त कमिट्स (गिट कम-मी "कमिट मैसेज") बनाना संभव है। कोड की समीक्षा के दौरान, नई कार्यक्षमता के साथ एक शाखा में और उन्हें केंद्रीय भंडार (git push -u origin MYFEATURE) में भेजना। समीक्षा के सफल समापन के बाद, टीम का नेतृत्व (या अभिनय) शाखाओं के विलय की पुष्टि करता है। यहाँ विलय के बाद शाखा को हटाने के लिए ध्वज को स्थापित करना अतिशयोक्ति नहीं है - अन्यथा शाखाओं की संख्या जल्दी से अशोभनीय पैमाने पर बढ़ सकती है।

GitLab रिपॉजिटरी में निरंतर एकीकरण सुनिश्चित करने के लिए, एक वेब हुक "एकीकरण" खंड में कॉन्फ़िगर किया गया है, जो जेनकिंस कार्यों को परीक्षण वातावरण पर नई कार्यक्षमता बनाने और स्थापित करने के लिए कहता है। जेनकिन्स, Git के साथ काम करने के लिए प्लग-इन का उपयोग करते हुए, स्रोत कोड को डाउनलोड करता है, उससे कार्य का नाम प्राप्त करता है और Jira API का उपयोग उन घटकों की एक सूची का अनुरोध करने के लिए करता है जिन्हें बदल दिया गया है और उन्हें इकट्ठा करने की आवश्यकता है, बिल्ड प्रक्रिया शुरू करें, यूनिट परीक्षण चलाएं और निर्मित कलाकृतियों को लोड करें यदि वे सफलतापूर्वक पारित हो जाते हैं Sonatype Nexus पर और परीक्षण वातावरण पर उन्हें स्थापित करता है। यदि किसी एक चरण में विफलता होती है या यूनिट परीक्षण विफल हो जाते हैं, तो टेलीग्राम प्लग-इन की मदद से विकास टीम को बिल्ड परिणाम के बारे में सूचित किया जाता है। यदि स्थापना सफल रही, तो QA टीम को सूचित किया जाता है कि कार्य परीक्षण के लिए तैयार है।

यदि दोष दिखाई देते हैं, तो विकसित शाखा का वर्तमान संस्करण डाउनलोड किया जाता है और विकास शाखा के साथ MYFEATURE शाखा के मर्ज कमिट से हॉटफिक्स-MYFEATURE शाखा बनाई जाती है (git checkout [BASECOMMIT] -b हॉटफिक्स-MYFEATURE)।

बनाते समय, एक चेकआउट स्वचालित रूप से बनाई गई शाखा में किया जाता है, सुधार किए जाते हैं और स्थानीय शाखा हॉटफिक्स-MYFEATURE के लिए प्रतिबद्ध हैं (git प्रतिबद्ध हॉटफिक्स-MYFEATURE -m "प्रतिबद्ध संदेश")। जब सुधार पूरा हो जाता है और परीक्षण के वातावरण में प्रस्तुत करने के लिए तैयार होता है, तो उन्हें एक ही नाम (git push -u origin हॉटफिक्स-MYFEATURE) के साथ एक दूरस्थ शाखा में धकेल दिया जाता है और विकसित शाखा के साथ एक मर्ज अनुरोध बनाया जाता है।

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

यदि सभी दोषों को ठीक किया जाता है, तो विकसित शाखा का वर्तमान संस्करण डाउनलोड किया जाता है और हॉटफिक्स-MYFEATURE शाखा के मर्ज कमिट से विकसित शाखा में, रिलीज़-एमएन शाखा बनाई जाती है (git flow release start RELEASENAME [BASECOMMIT])।

रिलीज़ शाखा बनाना, जेनकिंस में एक कार्य को शुरू करने के लिए एक वेब हुक के लॉन्च की भी शुरुआत करता है, जो कि Git से स्रोत कोड डाउनलोड करता है, इससे रिलीज़ शाखा का नाम प्राप्त करता है और, Jira API का उपयोग करते हुए, उन घटकों की सूची पर सवाल उठाता है जो रिलीज़ कार्यों के भाग के रूप में परिवर्तित किए गए थे, Sonatype Nexus से वर्तमान संस्करणों को डाउनलोड करता है। और उन्हें एक प्रतिगमन परीक्षण वातावरण के लिए सेट करता है। प्रतिगमन परीक्षण वातावरण पर रिलीज़ की स्थापना के बाद, स्क्रिप्ट परीक्षण (अनुप्रयोग पुनरारंभ, डेटाबेस की सफाई, आदि) के लिए वातावरण तैयार करने के लिए चलाए जाते हैं और प्रतिगमन स्वयं-परीक्षण मुख्य सिस्टम कार्यक्षमता के संचालन की जांच करने के लिए चलाए जाते हैं, जिसके परिणामस्वरूप जेनकिंस के लिए ऑल्योर रिपोर्ट प्लगइन का उपयोग करके एक रिपोर्ट मिलती है। स्थापना के बाद, QA टीम को ऑटोटेस्ट रन के परिणामों और मैनुअल रिग्रेस परीक्षण के लिए रिलीज़ की तत्परता के बारे में टेलीग्राम में सूचित किया जाता है।

यदि प्रतिगमन परीक्षण के दौरान दोष दिखाई देते हैं, तो रिलीज़-एमएन शाखा का वर्तमान संस्करण डाउनलोड किया जाता है और, अंतिम प्रतिबद्ध से, जीरा (गिट चेकआउट -bb जीबी (BUGNAME [BASECOMMIT]) में दोष) के नाम से हॉटफिक्स / BUGNAME शाखा बनाई जाती है।

एक चेकआउट स्वचालित रूप से बनाई गई शाखा के लिए किया जाता है, आवश्यक सुधार किए जाते हैं और परिवर्तन स्थानीय शाखा हॉटफिक्स / BUGNAME (git प्रतिबद्ध हॉटफिक्स / BUGNAME -m "प्रतिबद्ध संदेश") के लिए प्रतिबद्ध हैं। जब सुधार पूरा हो जाता है और प्रतिगमन परीक्षण के वातावरण में प्रस्तुत करने के लिए तैयार होता है, तो उन्हें एक ही नाम (git push -u origin हॉटफिक्स / BUGNAME) के साथ एक दूरस्थ शाखा में धकेल दिया जाता है और रिलीज़-एमएन शाखा के साथ एक मर्ज अनुरोध बनाया जाता है

मर्ज का अनुरोध करने के लिए, डेवलपर मर्ज विरोधों (यदि कोई हो) को हल करता है और एक कोड समीक्षा करता है, जिसके दौरान कोड समीक्षा के दौरान प्राप्त टिप्पणियों के सुधार के साथ अतिरिक्त कमिट बनाना संभव है। ये कमिट स्थानीय शाखा हॉटफ़िक्स / BUGNAME (git प्रतिबद्ध हॉटफ़िक्स / BUGNAME -m "कमिट मैसेज") के लिए भी किए जाते हैं और इन्हें एक ही नाम (git पुश -u ओरिजनल हॉटफ़िक्स / BUGNAME) के साथ किसी दूरस्थ शाखा में धकेल दिया जाता है। समीक्षा सफलतापूर्वक पूर्ण होने के बाद, शाखाएँ विलीन हो जाती हैं। मर्ज पिछले एक के समान जेनकिंस में किसी कार्य को शुरू करने के लिए एक वेब हुक के लॉन्च की शुरुआत करता है, लेकिन इसमें अलग है कि यह Git से कोड को डाउनलोड करता है, इससे दोष का नाम प्राप्त करता है, Jira API का उपयोग उन घटकों की एक सूची का अनुरोध करने के लिए करता है जो फिक्स के भाग के रूप में बदल गए थे, इन घटकों को इकट्ठा करें, सोनाटाइप नेक्सस पर डाउनलोड और एक प्रतिगमन परीक्षण वातावरण पर उन्हें स्थापित करता है। इसके अलावा, सादृश्य द्वारा, पर्यावरण को ऑटोटेस्टिंग के लिए तैयार किया जाता है, प्रतिगमन ऑटोटेस्ट चलाया जाता है, और इसके परिणाम अधिसूचित किए जाते हैं।

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

जब इसे बनाया जाता है, तो यह जेनकिन्स में टास्क को कॉल करने के लिए वेब हुक के लॉन्च की पहल करता है, जो Git से सोर्स कोड डाउनलोड करता है, इससे रिलीज़ नंबर प्राप्त करता है, और Jira API का उपयोग करते हुए, उन कार्यों की सूची का अनुरोध करता है, जो रिलीज़ में शामिल थे और इन कार्यों के हिस्से के रूप में बदले गए घटकों को शामिल किया गया था, जो सोनटाइप नेक्सस से कलाकृतियों के वर्तमान संस्करण को निकालता है और उन्हें एक उत्पादक वातावरण पर स्थापित करता है।

बिक्री के लिए हॉटफ़िक्स के साथ, यह रिलीज़ एक के समान एक प्रक्रिया का उपयोग करने का निर्णय लिया गया - अन्यथा किए गए परिवर्तनों के परीक्षण चरणों को खो दिया जाएगा।

प्रक्रिया को लागू करते समय, उन कर्मचारियों के लिए प्रशिक्षण भी आयोजित किया गया था जिनके पास गिट और गिटलैब के साथ काम करने का अनुभव नहीं था, जिसके लिए एक उपयुक्त प्रशिक्षण कार्यक्रम विकसित किया गया था। इसके साथ, आप स्वयं Git के साथ काम करने के लिए Source Tree और Intellij IDEA का उपयोग करने के लिए प्रशिक्षण का संचालन कर सकेंगे, साथ ही GitLab कोड की समीक्षा करने के लिए भी। अगले पोस्ट में, मैं उसे दे दूंगा, चित्र के साथ पूरक।