क्या टीम या ऐप का आकार रिलीज़ प्रक्रिया को प्रभावित करता है? खैर यह निर्भर करता है। आइए एक छोटी टीम के साथ एक स्टार्टअप की कल्पना करें। इस मामले में, टीम आमतौर पर एक फीचर बनाती है और फिर उसे जारी कर देती है। अब, आइए एक बड़े प्रोजेक्ट की कल्पना करें, उदाहरण के लिए, एक बैंकिंग ऐप, जिस पर कई टीमें काम कर रही हैं।

इस मामले में, संभवतः एक प्रक्रिया, रिलीज़ चक्र और शायद कुछ नौकरशाही होनी चाहिए। उसके बिना, अराजकता होगी.

तो, यह कब स्पष्ट हो जाता है कि आपके ऐप के लिए ऐसी प्रक्रिया स्थापित करने का समय आ गया है?

इस लेख में, मैं डोडो पिज्जा ऐप (एंड्रॉइड और आईओएस) के लिए रिलीज ट्रेन को लागू करने के अपने अनुभव और उन समस्याओं को साझा करूंगा जिनके कारण हमारी टीम को रिलीज ट्रेन को लागू करना पड़ा।

यदि आप किसी ऐसे एंड्रॉइड या आईओएस प्रोजेक्ट के टीम लीड/टेक लीड हैं जो तेजी से बढ़ रहा है और आपने अभी तक रिलीज प्रक्रिया को प्रबंधित नहीं किया है, तो मुझे उम्मीद है कि हमारा अनुभव आपकी मदद करेगा।

यह कैसे हुआ करता था

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

रिलीज़ प्रक्रिया बहुत सरल थी: जो कोई भी अपनी सुविधा को रोल आउट करने के लिए तैयार था, उसने इसे रोल आउट कर दिया।

आदर्श परिदृश्य

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

उदाहरण के लिए, ग्रे टीम ने 4 चरणों में अपना फीचर बनाया, नीली और नारंगी टीमों ने 1 चरण में अपना फीचर बनाया, और हरी टीम ने 2 चरणों में अपना फीचर बनाया।

जब कोई टीम किसी सुविधा को पूरा कर लेती है, तो वे एक रिलीज़ जारी कर सकते हैं। उदाहरण के लिए, यदि ब्लू टीम ने एक फीचर पूरा कर लिया है, तो वे एक रिलीज कर सकते हैं। फिर, ऑरेंज टीम एक फीचर खत्म करेगी और दूसरी रिलीज करेगी।

हमारे पास एकदम सही प्रवाह था, जैसा कि तब लगता था। एक बिंदु तक इसने बहुत अच्छा काम किया, लेकिन सभी अच्छी चीज़ों का अंत हो जाता है।

कुछ गलत हुआ: कठिन, भीड़भाड़ वाला और अप्रत्याशित

विशाल

पहली समस्या जो हमारे सामने आई वह यह थी कि रिलीज़ में बहुत सारी सुविधाएँ जमा होने लगीं और वे बहुत बड़ी हो गईं।

टीमें हमेशा अपनी सुविधाओं को तुरंत जारी नहीं करना चाहती थीं। रिलीज़ और रिग्रेशन प्रक्रिया समय लेने वाली थी और इसमें 3-4 दिन लग गए। इसलिए यदि आपकी सुविधा छोटी थी और अत्यावश्यक नहीं थी, तो आप हमेशा इसे स्वयं रिलीज़ नहीं कर पाते थे क्योंकि संभवतः, कोई अन्य टीम जल्द ही रिलीज़ करेगी, और इसे उस रिलीज़ में शामिल किया जाएगा। मोटे तौर पर यह इस तरह दिखता था:

यह काफी नाजुक व्यवस्था थी, खासकर जब टीमों की संख्या बढ़ने लगी। कई टीमों ने कई छोटी-छोटी सुविधाएँ विकसित कीं, और प्रत्येक नई रिलीज़ में नए कोड की कुल मात्रा बहुत बड़ी हो गई। जब किसी को अपना बड़ा फीचर जारी करना होता था, तो उन्हें उसके साथ एक पूरा मैमथ भी जारी करना पड़ता था।

मैमथ-रिलीज़ के परिणामस्वरूप:

• विलंबित प्रतिगमन;

• प्रतिगमन बग का उच्च जोखिम;

• उत्पादन में बग आने का अधिक जोखिम।

हमें इसे बनाने की ज़रूरत थी ताकि भले ही उदाहरण से नीली और नारंगी टीम रिलीज़ नहीं करना चाहती हो, लेकिन रिलीज़ किसी भी तरह की जा सके।

बाधाओं

प्रत्येक टीम अद्वितीय है, और प्रत्येक विशेषता भिन्न है। कभी-कभी, चीजें इस तरह से घटित होती थीं कि कई टीमें एक ही समय में अपनी सुविधाएँ समाप्त कर लेती थीं। इस मामले में, बहुत कुछ था "मेरे लिए प्रतीक्षा करें, मैं इसे कल सुबह विलय कर दूंगा, मैं वादा करता हूं!" कहीं जा रहे हैं।

अंत में, ऐसी बाधाओं के परिणामस्वरूप:

• रिलीज़ मैमथ में बदल जाती है;

• देरी से रिलीज़ होने से रिलीज़ करने वाली टीम की योजनाओं पर नकारात्मक प्रभाव पड़ता है, खासकर तब जब बाकी सभी की ज़रूरतें पूरी हो जाती हों।

हमें 2 महत्वपूर्ण परिवर्तन करने की आवश्यकता थी:

1. रिलीज़ करने वाली टीम को किसी का इंतज़ार करने की ज़रूरत नहीं होनी चाहिए;

   
   

2. हर दूसरी टीम को पता होना चाहिए कि अगली रिलीज़ कब अपेक्षित है।

पूर्वानुमेयता का अभाव

कल्पना कीजिए, नीली टीम ने एक छोटा सा फीचर बनाया और उम्मीद की कि नारंगी टीम इसे जल्द ही जारी करेगी। लेकिन कुछ ग़लत हो गया, और ऑरेंज टीम ने अपनी कुछ समस्याओं के कारण रिलीज़ जारी नहीं की।

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

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

जैसा कि आप अनुमान लगा सकते हैं, हम अक्सर ऐसे मुद्दों का सामना कर रहे थे। हमें यह बताने में सक्षम होने की आवश्यकता है कि ग्राहकों को उत्पादन में कोई सुविधा कब मिलेगी, चाहे उसका आकार या तात्कालिकता कुछ भी हो। सभी 3 समस्याएं (विशाल रिलीज, बाधाएं, और पूर्वानुमान की कमी) बारीकी से संबंधित हैं और एक-दूसरे की पूरक हैं।

हालाँकि, संभवतः उनमें से सबसे मौलिक और महत्वपूर्ण पूर्वानुमान की कमी है। यह अन्य समस्याएँ उत्पन्न करता है।

ट्रेन जारी करें

हमारे पास बहुत कुछ है; यह बदलाव करने का समय था। रिलीज़ ट्रेन को ऐसा करने में हमारी मदद करनी थी।

रिलीज़ ट्रेन शब्द का अर्थ अलग-अलग चीजें हैं: एक निर्धारित रिलीज़ प्रक्रिया , या एक समर्पित टीम जो रिलीज़ प्रक्रिया का प्रबंधन करती है। यहां, हम निर्धारित रिलीज़ प्रक्रिया के बारे में बात करने जा रहे हैं।

मुझे " स्रोत कोड शाखाओं के प्रबंधन के लिए पैटर्न " लेख में मार्टिन फाउलर द्वारा रिलीज़ ट्रेन का वर्णन करने का तरीका और थॉटवर्क्स द्वारा उनके तकनीकी रडार में दी गई परिभाषा पसंद है (शायद यह मार्टिन की भी है)।

इस प्रकार हमने अपने लिए रिलीज़ ट्रेन को परिभाषित किया है:

रिलीज़ ट्रेन टीमों के बीच रिलीज़ के समन्वय की प्रक्रिया है। सभी रिलीज़ एक निश्चित समय पर होती हैं, चाहे सुविधाएँ तैयार हों या नहीं। ट्रेन किसी का इंतजार नहीं करती. यदि आप देर कर चुके हैं, तो आपको अगले का इंतजार करना होगा।

आइए हमारी रंग-कोडित टीमों का उपयोग करके इसे कुछ उदाहरणों से तोड़ें।

विशाल समस्या का समाधान

रिलीज़ ट्रेन निर्धारित समय पर होती है और यह इस बात पर निर्भर नहीं करती कि किसने मुख्य शाखा में क्या विलय किया है। नीचे दिए गए उदाहरण में, नीली और नारंगी टीमों की सुविधाएँ जारी की जाएंगी। बाकी लोग अगली ट्रेन का इंतजार करेंगे. हम थोड़ा और इंतजार कर सकते थे, लेकिन फिर हमें एक विशाल जानवर मिलेगा।

बाधाओं का समाधान

साथ ही, रिलीज़ ट्रेन हमें अपने काम की अधिक कुशलता से योजना बनाने में मदद करती है। मान लीजिए कि ब्लू टीम ने मूल रूप से एक फीचर को बाद में समाप्त करने की योजना बनाई थी। लेकिन चूँकि सभी को रिलीज़ की तारीख पता है, इसलिए वे सुविधा को जल्दी ख़त्म करने के लिए अपनी योजनाओं को थोड़ा पुनर्व्यवस्थित कर सकते हैं।

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

नीचे दिए गए उदाहरण में, ब्लू टीम रिलीज़ तक पहुंचना चाहती थी और रिलीज़ से पहले अपने सभी परिवर्तनों को मर्ज करना चाहती थी। नहीं तो कोई अड़चन आ सकती थी.

सबसे महत्वपूर्ण बात यह है कि रिलीज़ ट्रेन ने हमें डिज़ाइन के आधार पर पूर्वानुमेयता प्रदान की ।

ये उदाहरण कुछ लोगों को स्पष्ट लग सकते हैं, लेकिन हमने समस्याएँ उत्पन्न होते ही उनका समाधान कर दिया। जब रिलीज़ में कोई समस्या नहीं थी, तो हमने रिलीज़ ट्रेन का उपयोग करने की जहमत नहीं उठाई। जब समस्याएँ बढ़ती गईं, तो हमें एहसास हुआ कि समय आ गया है।

अपनी टीम में रिलीज़ ट्रेन को कैसे कार्यान्वित करें

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

डोडो इंजीनियरिंग में, हम आरएफसी और एडीआर दोनों का उपयोग करते हैं।

हमारी RFC प्रक्रिया इस प्रकार दिखी:

1. हमने एक RFC दस्तावेज़ का मसौदा तैयार किया;

   
   

2. हमने एक छोटे समूह में इस पर चर्चा की, टिप्पणियाँ एकत्र कीं और समायोजन किया;

   
   

3. फिर आरएफसी को एक व्यापक समूह को सूचित किया गया;

   
   

4. फिर हमने इसे लागू किया;

   
   

5. उसके बाद, हमने फीडबैक एकत्र किया, मेट्रिक्स को ट्रैक किया और परिणामों का मूल्यांकन किया।

हमारी रिलीज़ ट्रेन के लिए RFC दस्तावेज़ की संरचना इस प्रकार थी:

• रिलीज़ ट्रेन प्रक्रिया का विवरण;

• कौन सी टीमें शामिल हैं, वे क्या कर रही हैं;

• कार्यक्रम क्या होगा;

• मेट्रिक्स.

आरएफसी का मसौदा तैयार करने में, हमने अन्य कंपनियों के अनुभव पर भरोसा किया:

• Skyscanner
• Soundcloud
• मोंज़ो
• फेसबुक

पहला कार्यान्वयन

सबसे पहले, हम इस प्रक्रिया के साथ आए:

• हर सप्ताह जारी करें;

• बुधवार की सुबह एक रिलीज़ शाखा बनाएँ;

• पूर्ण वापसी, और शुक्रवार को समीक्षा के लिए ऐप भेजें;

• सोमवार से रिलीज़ शुरू करें।

• रिलीज़ टीम:

  • फीचर टीमों में से एक से 1 आईओएस और 1 एंड्रॉइड डेवलपर्स;

  • 2 क्यूए इंजीनियर।

    
    

• बुधवार को एक नई रिलीज़ शाखा बनाएँ;

• एक चौथाई आगे का शेड्यूल बनाएं, जिसमें यह दर्शाया जाए कि प्रत्येक टीम की रिलीज़ की बारी कब है। एक तिमाही के बाद एक साथ मिलें और शेड्यूल बढ़ाएँ।

योजनाबद्ध रूप से, हमारी रिलीज़ ट्रेन इस तरह दिखती थी:

यह सब सुचारू रूप से नहीं चला

एक महीने के बाद, यह स्पष्ट हो गया कि यद्यपि पहला अनुभव बहुत अच्छा लगा,

• हर सप्ताह वापसी करना और शुक्रवार तक इसे पूरा करना वास्तव में कठिन था;

• हॉटफ़िक्स के लिए कोई समय नहीं था, और वे कभी-कभी होते थे।

2021 में, हमारे प्रतिगमन परीक्षण में औसतन 3-4 दिन लगते थे। हम 2022 में इसे 2-3 दिन तक छोटा करने में कामयाब रहे, लेकिन कभी-कभी, यह उस समय सीमा से अधिक हो जाती थी। हमने e2e परीक्षणों के साथ प्रतिगमन मामलों को कवर करना जारी रखा, लेकिन हमारे पास अभी तक 100% कवरेज नहीं था। हमारे पास प्रत्येक प्लेटफ़ॉर्म पर प्रतिगमन मामलों का क्रमशः लगभग 70% और 60% कवरेज था।

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

अंतिम उत्तर

हम 2-सप्ताह के रिलीज़ चक्र पर चले गए, और रिलीज़ ट्रेन अब इस तरह दिखती है:

• हर 2 सप्ताह में रिलीज़ करें;
• बुधवार की सुबह एक रिलीज़ शाखा बनाएँ;
• वापस आएं, और ऐप को शुक्रवार को समीक्षा के लिए भेजें;
• सोमवार से रिलीज़ शुरू करें।

• रिलीज़ टीम:

  • फीचर टीमों में से एक से 1 आईओएस और 1 एंड्रॉइड डेवलपर्स;

  • 2 क्यूए इंजीनियर।

    
    

• एक चौथाई आगे का शेड्यूल बनाएं, जिसमें यह दर्शाया जाए कि प्रत्येक टीम की रिलीज़ की बारी कब है। एक तिमाही के बाद, एक साथ मिलें और शेड्यूल बढ़ाएँ।
• रिलीज को धीरे-धीरे रोल आउट करें;
• यदि आवश्यक हो तो हॉटफ़िक्सेस करें, अब जब हमारे पास उनके लिए समय हो;
• एक सप्ताह बाद बुधवार को, एक नई रिलीज़ शाखा बनाएँ।

यदि सब कुछ योजना के अनुसार चलता है तो प्रक्रिया इस प्रकार दिखती है:

यह सब एक साप्ताहिक चक्र की तरह दिखता है, सिवाय इसके कि संभावित हॉटफ़िक्स के लिए बहुत समय बचा है। विस्तारित प्रतिगमन परीक्षणों के मामले में यह इस तरह दिखेगा:

कोई बड़ी बात भी नहीं; हॉटफ़िक्स के लिए भी अभी भी समय है।

नई प्रक्रिया ने पूर्वानुमेयता को कैसे प्रभावित किया?

हमारे लिए मुख्य लक्ष्य पूर्वानुमेयता को बढ़ाना था। इसे दो भागों में विभाजित किया जा सकता है:

1. आवेदन कब जारी होगा;
2. मेरा फीचर किस रिलीज़ में आएगा?

हमने इस प्रश्न का उत्तर दिया "रिलीज़ कब होगी?" रिलीज़ ट्रेन प्रक्रिया को लागू करके। अब, प्रत्येक टीम इस प्रश्न का उत्तर देने में सक्षम होगी कि "मेरी सुविधा किस रिलीज़ में समाप्त होगी?" उस समय स्वतंत्र रूप से जब वे सुविधा की योजना बनाते हैं और उसका मूल्यांकन करते हैं।

पहले, यह निश्चित रूप से कहना असंभव था क्योंकि कोई अन्य टीम रिलीज़ कर भी सकती है और नहीं भी। अब सब कुछ उस टीम की अपनी प्लानिंग पर ही निर्भर करता है.

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

• अगली रिलीज़ कब है? (100% इस प्रश्न का उत्तर दिया गया)।

• क्या रिलीज़ ट्रेन ने आपको अपनी टीम वर्क की योजना बनाने में मदद की? (75% ने सकारात्मक उत्तर दिया, लेकिन कुछ ने रिलीज़ ट्रेन के बिना भी अपने काम की सटीक भविष्यवाणी की)।

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

मेट्रिक्स पर प्रभाव

समस्याओं को हल करने के अलावा, हमने मेट्रिक्स को भी मापा। आइए मुख्य बातों पर एक नजर डालें।

समय सीमा

पहला महत्वपूर्ण मीट्रिक जो हमने मापा वह रिलीज़ के लिए लीड टाइम प्रतिबद्धता थी।

ग्राफ़ इस प्रकार दिखता है. मैंने उस बिंदु को चिह्नित किया जब हमने एक तीर के साथ रिलीज़ ट्रेन प्रक्रिया शुरू की थी।

ग्राफ़ से पता चलता है कि लीड टाइम लगभग छह दिनों तक कम हो गया है। छह दिन लंबा समय है या छोटा?

गूगल बेंचमार्क

वहाँ हैं इस मीट्रिक के लिए Google से बेंचमार्क , लेकिन यह अधिकतर बैकएंड के लिए है। अपने पैमाने के आधार पर, वे निम्नलिखित समूहों को अलग करते हैं:

• विशिष्ट वर्ग: एक घंटे से भी कम
• उच्च: 1 घंटा से 1 सप्ताह तक
• मध्यम: 1 सप्ताह से 6 महीने तक
• कम: 6 महीने या उससे अधिक

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

बग प्रति प्रतिगमन

एक अन्य मीट्रिक जिसे हम ट्रैक करते हैं वह प्रति प्रतिगमन बग की संख्या है। यह बताता है कि रिलीज़ उम्मीदवार कितना स्थिर है। यदि पिछली रिलीज़ बहुत समय पहले हुई थी, तो हमने संभवतः बहुत सारे नए कोड बनाए होंगे जिनमें संभावित रूप से बड़ी संख्या में बग हो सकते हैं, और हम रिग्रेशन और फिक्स पर अधिक समय व्यतीत कर सकते हैं।

एक समय पर, यह मीट्रिक तीन बग तक नीचे थी। विशिष्ट संख्याएँ इतनी महत्वपूर्ण नहीं हैं, लेकिन कुल मिलाकर, आप देख सकते हैं कि प्रवृत्ति में गिरावट आई है।

अधिक मेट्रिक्स

मैं संक्षेप में चर्चा करूंगा कि रिलीज ट्रेन के हिस्से के रूप में किन मेट्रिक्स की निगरानी की गई थी।

• क्रैश-मुक्त. हम हमेशा इस मीट्रिक पर नज़र रखते हैं. ऐसी परिकल्पना थी कि प्रतिगमन को एक सख्त समय सीमा में फिट करने के हमारे प्रयासों के कारण इसमें गिरावट आएगी। खैर, कोई गिरावट नहीं हुई.

• हमें आश्चर्य हुआ कि क्या बार-बार (साप्ताहिक) रिलीज़ का ग्राहक मंथन और ऐप को हटाने पर प्रभाव पड़ेगा। परिणामस्वरूप, हमें कोई प्रभाव नहीं मिला।

कार्यान्वित करें, सुधार करें

हमें मौजूदा प्रक्रिया पसंद है क्योंकि हमें लगता है कि इसने अपने लक्ष्य हासिल कर लिए हैं। हम यह भी जानते हैं कि इसे और कैसे बेहतर बनाया जाए:

• हम प्रतिगमन को सरल और तेज़ बनाने के लिए इसे स्वचालित करने पर काम करना जारी रखते हैं।

• अब तक, हमने कार्य स्वचालन (शाखाओं के लिए स्क्रिप्ट) के हिस्से को छोड़ दिया है, लेकिन यह भी भविष्य में विकास का एक बड़ा बिंदु होगा।

• हमारा ऐप 20 देशों में काम करता है, और हमें एप्लिकेशन को कई अलग-अलग भाषाओं में अनुवाद करने की आवश्यकता है। इसके लिए एक आंतरिक सेवा है, लेकिन डेवलपर्स को अभी भी रिलीज़ से पहले इस प्रक्रिया में मैन्युअल रूप से भाग लेना होगा। इस प्रक्रिया को स्वचालित करने से संभावित रूप से रिलीज़ चक्र में और भी सुधार हो सकता है।

सारांश

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

अब, हमारे पास रिलीज़ की पूर्वानुमेयता है, और मेट्रिक्स सकारात्मक गतिशीलता दिखाते हैं। हम e2e-परीक्षणों के साथ प्रतिगमन मामलों के कवरेज को बढ़ाने, शाखाओं के साथ काम करने की प्रक्रिया को स्वचालित करने और अनुवाद की प्रक्रिया को अनुकूलित करने की योजना बना रहे हैं।

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

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

और ट्विटर पर मुझे फॉलो करें . आमतौर पर, मैं सामान्य तौर पर एंड्रॉइड डेवलपमेंट और सॉफ्टवेयर इंजीनियरिंग के बारे में पोस्ट करता हूं।

यहाँ भी प्रकाशित किया गया