अपनी रिलीज़ को अपग्रेड करें

हेनरी फोर्ड ने एक बार कहा था: "सबसे अच्छी कार एक नई कार है।" इसलिए हम Tinkoff समूह की कंपनियों में सॉफ्टवेयर रिलीज़ के बारे में सोचते हैं। जल्दी और बाद में सुविधाओं को देने और तत्काल सुधार करने की प्रक्रिया में जड़ता ग्राहक को एक बड़े तकनीकी ऋण की ओर ले जाती है और अधिकतर परियोजना के ठहराव के साथ समाप्त होती है।

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

हमारा अनुभव सफलता के निर्देशों के रूप में शायद ही गौर करने लायक है, लेकिन आपके साथ साझा करने के लिए कई विचार मुझे काफी दिलचस्प लगे। चलिए शुरू करते हैं।

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

हम Gitflow पर काम करते हैं, इसलिए लेख उन लोगों के लिए मुख्य रूप से दिलचस्प होगा जिन्होंने इस विशेष वितरण पद्धति को चुना।

समस्याओं

पहली समस्या जिसका हमें सामना करना पड़ा, वह प्रक्रियाओं के अपर्याप्त स्वचालन से संबंधित है । हमारी टीम में सभी रिलीज गतिविधियों का कार्यान्वयन एक रिलीज मैनेजर (आरएम) की भूमिका से जुड़ा हुआ है।

यहाँ उनमें से कुछ हैं:

1. रिलीज़ ब्रांच छोड़कर टैग बनाना।
2. मास्टर के साथ विलय और शाखाओं का विकास।
3. रिलीज में शामिल कलाकृतियों का निर्माण और तैनाती करें।
4. प्रक्रिया में शामिल विशेषज्ञों के साथ संचार - उदाहरण के लिए, क्यूए या प्रशासकों के साथ।

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

रिलीज मैनेजर को अभी भी विलय की शाखाओं से उत्पन्न होने वाले संभावित संघर्षों को मैन्युअल रूप से हल करना होगा, लेकिन त्वरित और लगातार रिलीज से उनकी संख्या घटकर कुछ भी नहीं होनी चाहिए।

अगली समस्या परीक्षण की है ।

हमारे लिए निर्माण मानदंडों में से एक परीक्षण का सफल निष्पादन है। यह परीक्षणों को कम से कम दो प्रकारों में विभाजित करने के लिए प्रथागत है: इकाई और एकीकरण।

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

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

वास्तव में, वे कई आस्थगित समस्याएं पैदा करते हैं, यहां उनमें से कुछ हैं:

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

अधिकांश समस्याओं के लिए पहले से ही एक समाधान है। लेकिन, हमेशा की तरह, अतिरिक्त प्रतिबंध या नई समस्याओं के बिना समाधान नहीं आते हैं।

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

हमारे मामले में, हम एक संकर पर बसे। हम एक पूर्ण सुविधा परीक्षण के लिए सभी आवश्यक घटकों को उठाना जारी रखते हैं, साथ ही साथ सभी संभव एकीकरण को धोते हैं। API कॉन्ट्रैक्ट को बचाने के लिए, हम Pact का उपयोग करते हैं, और डेटाबेस के साथ एकीकरण की जांच करने के लिए - Testcontainers ।

परिणामस्वरूप परीक्षण लिखने के लिए इस तरह के दृष्टिकोण से तीसरी समस्या का समाधान हुआ - एक कार्य के मैनुअल परीक्षण के लिए एक लंबा समय । हाइब्रिड परीक्षणों की स्थिरता ने परीक्षण मामलों को संकलित करने के लिए कार्य को निर्दिष्ट करने के चरण में एक क्यूए इंजीनियर को आकर्षित करने के विचार को प्रेरित किया है - यह उन्हें मैनुअल परीक्षण के चरण में छोड़ दिया जाएगा। उपयोगी उत्पादों जैसे कि TestRail और Allure के साथ एकीकरण डेवलपर और परीक्षक के बीच एक प्रकार का पुल बन गया है। एक अनुबंध बनाया जाता है, जिसका निष्पादन परीक्षण विधानसभा के दौरान उत्पन्न रिपोर्ट में दर्शाया गया है।

यह पारदर्शी कार्य ट्रैकिंग के लिए रिपोर्ट को आपके कार्य-ट्रैकिंग टूल से जोड़ने के लिए बना हुआ है। एक स्पष्ट कहानी भविष्य में संबंधित कार्यों के लिए परीक्षणों को संकलित करने और लागू करने में लगने वाले समय को भी कम कर देगी।

इस तरह, क्यूए इंजीनियर असाधारण मामलों के परीक्षण और अन्य प्रणालियों के साथ एकीकरण करने पर ध्यान केंद्रित करने के लिए पर्याप्त समय बचाते हैं।

आखिरी समस्या इसी से जुड़ी है। मैनुअल परीक्षण के लिए, सभी कार्य फीचर शाखाओं से मर्ज हो जाते हैं और टेस्ट बेंच में एक तैनाती शुरू करते हैं।

सबसे पहले, इस दृष्टिकोण के साथ, आप फीचर के शुद्ध परीक्षण के बारे में बात नहीं कर सकते, क्योंकि समानांतर में अन्य डेवलपर्स के संबंधित परिवर्तन विकसित हो सकते हैं।

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

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

इस अवसर को महसूस करने के बाद, हमने अलग-अलग फ़ीचर शाखाओं पर सीधे मैनुअल परीक्षण करना शुरू किया: परीक्षण की अवधि के लिए आवश्यक सेवा को तैनात करना, अलगाव में समग्र वातावरण को एकीकृत करना। केवल तैयार कार्यों को विकसित शाखा में विलय करके और ताले से छुटकारा पाकर, हम खुद यह निर्धारित करने लगे कि किन बदलावों को रिलीज में शामिल किया जाना चाहिए और कौन सा नहीं होना चाहिए।

यह ध्यान देने योग्य है कि इस तरह के समाधान से उन टीमों के लिए चांदी की गोली बनने की संभावना नहीं है जो लगभग एक ही फाइल में बदलाव करते हैं। इस मामले में, सुविधाओं का भंडारण विलय के दौरान उत्पन्न होने वाले संघर्षों की संख्या के विपरीत आनुपातिक है। व्यवहार में, लगातार रिलीज के साथ, यह पचास डेवलपर्स वाली टीम में बहुत कम होता है।

आउटपुट के बजाय

संक्षेप में, हम मुख्य दृष्टिकोणों की पहचान कर सकते हैं जो रिलीज को तेज करने में मदद कर सकते हैं:

1. नियमित संचालन का स्वचालन।
2. सभी शामिल प्रक्रियाओं के लिए पारदर्शिता।
3. स्वचालित परीक्षण लिखने में गति और गुणवत्ता के बीच आवश्यक संतुलन।
4. मैनुअल परीक्षण के लिए कम समय।
5. परीक्षण के लिए पर्यावरण का अलगाव।

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