किसी परियोजना पर CI / CD को कैसे व्यवस्थित किया जाए: कार्यों को स्थापित करने से लेकर तैनाती पाइपलाइन की स्थापना तक

परियोजनाओं पर निरंतर वितरण को सफलतापूर्वक स्थापित करने की कुंजी क्या है? विकास, परीक्षण और बुनियादी ढाँचा इंजीनियरों का अच्छा समन्वित कार्य। धन्यवाद, टोपी, जैसा कि वे कहते हैं :) लेकिन इसे व्यवहार में कैसे लाया जाए? इस लेख में हम यह सब व्यवस्थित करने और इसे लागू करने के बारे में हमारी सर्वोत्तम प्रथाओं को साझा करेंगे।

हमने अपने लिए एक चीट शीट में मूल आधारभूत बातों को संक्षेप में प्रस्तुत किया है और आपके साथ साझा किया है:

• क्या आवश्यकताएं हैं और वे कैसे विशेषता हैं ,
• कार्यों के प्रकार और अंक ट्रैकर में उनके विवरण का क्रम ,
• यूजर स्टोरी और टेक स्टोरी कैसे बनाये ,
• बग का वर्णन कैसे करें
• तैनाती पाइपलाइन की स्थापना ।

अनुभवी इंजीनियरों को लेख से कुछ भी नया सीखने की संभावना नहीं है, लेकिन हमें उम्मीद है कि यह जानकारी शुरुआती लोगों के लिए उपयोगी होगी।

क्या आवश्यकताएं हैं और वे कैसे विशेषता हैं

प्रत्येक परियोजना की कई आवश्यकताएँ होती हैं। उन सभी को समझना महत्वपूर्ण है और भ्रमित नहीं होना चाहिए।

व्यावसायिक आवश्यकताएं निर्धारित करती हैं कि एक प्रणाली को व्यावसायिक दृष्टिकोण से क्या करना चाहिए।

उदाहरण के लिए: एप्लिकेशन को एजेंटों की बिक्री बढ़ाने के लिए उपयोगकर्ता को टिकट और अतिरिक्त सेवाएं बेचने की अनुमति देनी चाहिए।

उपयोगकर्ता आवश्यकताएं उपयोगकर्ताओं के लक्ष्यों और उद्देश्यों का वर्णन करती हैं जो व्यवसाय की आवश्यकताओं को लागू करने के लिए सिस्टम में काम करेंगे। उपयोगकर्ता की आवश्यकताओं को अक्सर उपयोगकर्ता मामलों के रूप में प्रस्तुत किया जाता है।

उदाहरण के लिए: एक उपयोगकर्ता के रूप में, मुझे मील के लिए सेवाएं बेचने की आवश्यकता है।

कार्यात्मक आवश्यकताएं - सिस्टम को क्या करना चाहिए। सिस्टम की कार्यक्षमता (व्यवहार) निर्धारित करें, जिसे डेवलपर्स द्वारा बनाया जाना चाहिए ताकि उपयोगकर्ता उपयोगकर्ता की आवश्यकताओं को पूरा कर सकें।

गैर-कार्यात्मक आवश्यकताएं - सिस्टम को कैसे काम करना चाहिए। इसमें प्रदर्शन, गुणवत्ता, सीमाएं, प्रयोज्य आदि की आवश्यकताएं शामिल हैं।

कार्यों के प्रकार और अंक ट्रैकर में उनके विवरण का क्रम

इसलिए, हमने आवश्यकताओं के प्रकारों का वर्णन किया है। अब हम उन्हें कार्यों के प्रकारों में तोड़ देंगे, प्रत्येक प्रकार को समझेंगे और बताएंगे कि इसे सही तरीके से कैसे वर्णित किया जाए।



आइए सबसे महाकाव्य के साथ शुरू करें, जो एपिक के साथ है।

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

महाकाव्य समस्या का समाधान आपको एमवीपी (न्यूनतम व्यवहार्य उत्पाद) बनाने की अनुमति देता है - न्यूनतम व्यवहार्य उत्पाद। दूसरे शब्दों में, अंतिम उपयोगकर्ताओं से प्रतिक्रिया के आधार पर उत्पाद को सीखने और अनुकूलित करने के लिए क्या जारी करने की आवश्यकता है।

एपिक यूजर स्टोरी से कैसे अलग है?

1. महाकाव्य सिर्फ एक बड़ी उपयोगकर्ता कहानी है, जिसकी पहचान उपयोगकर्ता के लिए एक स्पष्ट मूल्य की उपस्थिति है।
2. उपयोगकर्ता कहानियां बनाना शुरू करना, अर्थात्, एक परियोजना के लिए आवश्यकताओं को इकट्ठा करना, हम आम तौर पर सामान्य से विशेष तक बढ़ते हैं - पहले हम परियोजना की अवधारणा निर्धारित करते हैं, मुख्य व्यक्तियों (सिस्टम के उपयोगकर्ता) का चयन करते हैं, मुख्य विशेषताओं की एक सूची बनाते हैं, और फिर ये सुविधाएँ अलग-अलग इच्छाओं में विस्तृत होती हैं - उपयोगकर्ता की कहानी।

महाकाव्य का वर्णन इस प्रकार है:

1. शीर्षक / सारांश शीर्षक - नई कार्यक्षमता का नाम।
2. विवरण / विवरण - पैटर्न के अनुसार लिखा गया है:
   
   उपयोगकर्ता की भूमिका (जैसे कि एक उपयोगकर्ता, मैं ...) / उपयोगकर्ता कार्रवाई (मैं कुछ करना चाहता हूं ...) / कार्रवाई का परिणाम (ऐसा परिणाम प्राप्त करने के लिए कि ...) / ब्याज या लाभ (मुझे इस तरह के और ऐसे लाभ प्राप्त करने की अनुमति देगा ...)।
3. एक नमूना कार्यान्वयन योजना या मुख्य उपयोगकर्ता कहानियों का एक संक्षिप्त विवरण जिसे एमवीपी के साथ एपिक के हिस्से के रूप में लागू किया जाएगा।
4. संलग्नक / संलग्नक - पत्राचार, प्रौद्योगिकी और अन्य आवश्यक जानकारी संलग्न करें।

यूजर स्टोरी और टेक स्टोरी कैसे बनाये

उपयोगकर्ता की कहानी और टेक कहानी के बीच का अंतर यह है कि टेक स्टोरी कार्यात्मक आवश्यकताओं को संदर्भित करती है जिसे उत्पाद को विकसित करते समय कार्य में वर्णित और वर्णित किया जाना चाहिए। और यहां उपभोक्ताओं की भूमिका में सिस्टम के हिस्से हैं।

उनका वर्णन करना आसान है। याद रखने की मुख्य बात यह है कि यह सब क्यों किया जा रहा है।

उपयोगकर्ता कहानी विवरण आदेश बहुत मानक है:

1. शीर्षक / सारांश / शीर्षक - ग्राहक की समझ में आने वाली भाषा में नई कार्यक्षमता या सुधार का संक्षिप्त विवरण।
2. विवरण / विवरण में मुख्य लक्ष्य और वांछित परिणाम शामिल हैं। जैसे, <उपयोगकर्ता की भूमिका>, मैं <प्राप्त करना चाहता हूं>, कार्यों के परिणाम के लक्ष्य के साथ>।
3. स्वीकृति मानदंड प्राथमिकता उत्पाद मानदंड की एक सूची है। यही है, उत्पाद के साथ क्या किया जाना चाहिए की एक औसत दर्जे की परिभाषा है ताकि इसे परियोजना हितधारकों द्वारा स्वीकार किया जाए।
4. तकनीकी नोट, मॉडल, लेआउट, पेज लेआउट।
5. संलग्नक / संलग्नक - ग्राहक के साथ सभी आवश्यक प्रौद्योगिकियां, दस्तावेज, पत्राचार।

बग का वर्णन कैसे करें

बग की रिपोर्ट करते समय क्या जानकारी इंगित की जानी चाहिए:

1. शीर्षक / सारांश / शीर्षक संक्षेप में त्रुटि का सार बताता है और समस्या के स्थान को इंगित करता है।

2. विवरण में निम्नलिखित चरण हैं:

• त्रुटि / प्लेबैक चरणों को कैसे पुन: पेश करें,

• वर्तमान परिणाम,

• अपेक्षित परिणाम

3. संलग्नक / अटैचमेंट - सभी आवश्यक लॉग, स्क्रीनशॉट, किबाना और अन्य फाइलों के लिंक।

4. पर्यावरण - एक निशान जिसमें पर्यावरण में त्रुटि को पुन: पेश किया जाता है, और जिस श्रेणी में समस्या होती है। उदाहरण के लिए, एक यूआई त्रुटि, कोर त्रुटि, एसडब्ल्यूएस त्रुटि, आदि।

5. प्राथमिकता टीम के प्रत्येक सदस्य को समस्या की गंभीरता का आकलन करने की अनुमति देगी, और प्रबंधक इसे स्प्रिंट के लिए पहले उम्मीदवारों की सूची में देखेगा।

और सही प्राथमिकता स्तर सेट करने के लिए मत भूलना :)

अब जब हम काम के सामान्य सिद्धांतों को समझ गए हैं, तो हम आपको बताएंगे कि तैनाती पाइपलाइन कैसे व्यवस्थित करें।

तैनाती पाइपलाइन विन्यास

उत्पादन के लिए हमारी सेवाओं की डिलीवरी को गति देने के लिए, हम एक नई तैनाती पाइपलाइन पेश करते हैं और कोड के साथ काम करने के लिए GitFlow का उपयोग करते हैं।

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

प्रत्येक कमिटमेंट के लिए परीक्षण एकत्र करना और चलाना, इकाई परीक्षण और एकीकरण परीक्षण चलाना, अनुप्रयोग वितरण में कलाकृतियों को जोड़ना शुरू किया।



विकास इस तरह होता है:

1. डेवलपर एक अलग शाखा (सुविधा शाखा) में नई कार्यक्षमता जोड़ता है। उसके बाद, वह अपनी शाखा को विकास की मुख्य शाखा (मर्ज रिक्वेस्ट टू ब्रांच) के साथ विलय करने का अनुरोध करता है।
2. अन्य डेवलपर्स मर्ज अनुरोध को देखते हैं, इसे स्वीकार करते हैं (या नहीं) और टिप्पणियों को सही करते हैं। विलय के बाद, ट्रंक शाखा में एक विशेष वातावरण सामने आता है, जिस पर पर्यावरण को बढ़ाने के लिए परीक्षण किए जाते हैं।
3. जब ये सभी चरण पूरे हो जाते हैं, तो QA इंजीनियर अपनी "QA" शाखा में परिवर्तन करता है और परीक्षण करता है।
4. यदि QA इंजीनियर किए गए कार्य पर सहमत होता है, तो परिवर्तन रिलीज़-कैंडिडेट शाखा में जाते हैं और ऐसे वातावरण में तैनात होते हैं जो बाहरी उपयोगकर्ताओं के लिए सुलभ हो। इस वातावरण में, ग्राहक प्रौद्योगिकियों को स्वीकार और सत्यापित करता है। तब हम उत्पादन में सब कुछ आसवन करते हैं।

यदि किसी स्तर पर त्रुटियां हैं, तो यह इस शाखा में है कि हम उन्हें हल करते हैं, जिसके बाद हम परिणाम को पोस्ट करते हैं।

हमने एक छोटा प्लगइन भी बनाया ताकि Redmine हमें बता सके कि फीचर किस स्टेज पर है। यह परीक्षकों को इस बात का मूल्यांकन करने में मदद करता है कि आपको किस चरण में कार्य करने के लिए कनेक्ट करने की आवश्यकता है, और डेवलपर्स को त्रुटियों को ठीक करने के लिए। इसलिए वे देखते हैं कि विफलता किस चरण में हुई, एक विशिष्ट शाखा में जा सकते हैं और वहां खेल सकते हैं।



हमें उम्मीद है कि आप इसे मददगार पाएंगे।