रिलीज ट्रेन यैंडेक्स रिपोर्ट

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


- मेरे द्वारा लिए गए मोबाइल एप्लिकेशन के एंड्रॉइड-डेवलपर, मैं दिमित्री पॉलाकोव हूं।



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

अगला मैं आपको बताऊंगा कि हमारी रिलीज़ साइकिल कैसे काम करती है। प्रबंधक हमारे पास आते हैं और कहते हैं कि हम इस सुविधा को जल्द से जल्द समाप्त करना चाहते हैं। इसलिए, शायद, कोई भी प्रबंधक चाहता है, इसलिए हम रिलीज़ प्रक्रिया सेट करते हैं ताकि हम हर हफ्ते ऐप स्टोर और Google Play पर जाएं। मैं उन उपकरणों के बारे में भी बात करूंगा जो हमारे पास हैं और जो मैं आपको कोशिश करने की सलाह दूंगा, वे शांत हैं।

गित प्रवाह

चलिए Git Flow से शुरू करते हैं। एक आधार के रूप में, हमने क्लासिक गिट फ्लो लिया, हालांकि, यह हमारी परिस्थितियों में, हमारी टीम के तहत बहुत बदल गया है। तुम भी देखो, और शायद इस से कुछ तुम पर सूट करेगा, लेकिन कुछ नहीं। गिट के साथ काम करने के लिए प्रत्येक टीम का अपना दृष्टिकोण होता है।

यह हमारे साथ कैसे काम करता है? महाकाव्य आपकी सुविधा के लिए, कुछ बेहतरीन कार्यक्षमता के लिए मूल शाखा है। इसे और अधिक स्पष्ट करने के लिए, आइए तुरंत उत्पाद उदाहरण देखें।



प्रबंधक आता है और कहता है - डेवलपर, हमें एप्लिकेशन में चयनित उत्पादों के साथ इच्छा सूची की कार्यक्षमता बनाता है। डेवलपर एक नई शाखा महाकाव्य शुरू करता है और इसे इच्छा सूची कहता है।



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

जैसे ही वह एक ऐसी विशेषता पर काम पूरा करता है, वह पूल अनुरोध के माध्यम से इसे महाकाव्य में डाल देता है। पूल अनुरोध एक ऐसा तंत्र है जब आपकी टीम के अन्य डेवलपर्स आपके कोड की जांच करते हैं। यदि वे कुछ पसंद नहीं करते हैं, तो आपका कोड आपके महाकाव्य तक नहीं पहुंच सकता है, जिसका अर्थ है कि आपको तब तक जारी नहीं किया जाएगा जब तक आप उनके साथ समझौता नहीं करते।

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



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



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

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



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

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

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



उदाहरण के लिए, जैसे ही मॉस्को में आत्म-अलगाव मोड शुरू किया गया, हमारे पास एक उत्पाद की आवश्यकता थी ताकि उपयोगकर्ता संपर्क के बिना उत्पादों का ऑर्डर कर सकें। अब, हमारे आवेदन में एक आदेश देते समय, उपयोगकर्ता "दरवाजे पर छोड़ें" फ़ंक्शन का चयन कर सकता है। कूरियर आता है, दरवाजे के नीचे पार्सल छोड़ता है और बिना संपर्क के आपको इसे सौंप देता है।

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

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



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

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



महाकाव्य पर बहुत काम किया जा सकता है, और विकास में कोड के साथ बनाए रखने के लिए, डेवलपर कभी-कभी इसे अपने महाकाव्य में जोड़ता है, ताकि कम फ्रीज संघर्ष हो।



चूंकि हमने महाकाव्य में विकास को जोड़ा था, उसी कारणों से महाकाव्य को आपकी सुविधा में जोड़ने की आवश्यकता है।



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



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



मास्टर और विकसित शाखाएं हैं जो लगातार हमारे भंडार में रहते हैं। एक बार बनाया, और जीना। इसलिए, वे इतने रसीले नाम दिए गए हैं।

हम जिस तरह से जीते हैं। अब हम सहज, सुविधाजनक हैं।

रिलीज ट्रेन

हम अपनी रिलीज़ प्रक्रियाओं से गुजरते हैं। लेकिन इससे पहले कि हम रिलीज़ के बारे में बात करते हैं और हम उन्हें कैसे बनाते हैं, मैं उन भूमिकाओं के बारे में बात करूँगा जिन्हें हमें रिलीज़ का समर्थन करना है।

हमारे पास एक ऑन-कॉल डेवलपर है जो एक सप्ताह के भीतर उत्पाद कार्यों से निपटने के लिए बंद हो जाता है और मौजूदा रिलीज से बग को ठीक करता है। यदि उसके पास वर्तमान रिलीज़ के लिए कोई कार्य नहीं है, तो वह कुछ तकनीकी ऋणों को ठीक करेगा जो हमने जमा किए हैं, बैकलॉग से कार्य लेते हैं और उन्हें ठीक करते हैं।

ड्यूटी पर एक टेस्टर भी है। वह एक सप्ताह के भीतर उत्पाद कार्यों का परीक्षण करना भी बंद कर देता है और वर्तमान रिलीज़ की जाँच करता है। यदि उसके पास वर्तमान रिलीज़ के लिए कार्य नहीं हैं, तो वह परीक्षण करता है कि तकनीकी ऋण के हिस्से के रूप में क्या सही किया गया है।



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

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



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

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



मंगलवार को, हम अपनी रिलीज़ का परीक्षण करते हैं और रिलीज़ बग को ठीक करते हैं। दोपहर के बाद, हमारा प्रतिगमन परीक्षण समाप्त हो जाता है और हम गेट के लिए निकलने के लिए तैयार हैं। हम अपनी रिलीज़ ट्रेन लॉन्च करते हैं - वास्तव में, यहां तक ​​कि कई रिलीज़ ट्रेनें भी, क्योंकि हमने हाल ही में हमारे लिए एक नया बाज़ार बनाया है। मैं यह भी सलाह देता हूं कि आप न केवल Google Play पर, बल्कि कुछ अन्य लोगों में भी प्रकाशित करने का प्रयास करें। प्लस केवल यह नहीं है कि आपको एक नया वफादार दर्शक मिले।

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

जैसे ही हम Google Play पर अपडेट के साथ पहुंचे, हमने एक बड़ा बैनर देखा, जिसमें कहा गया था कि दुनिया की मौजूदा स्थिति के कारण, Google Play पर बहुत बड़ा भार है और उनके पास हमेशा की तरह अनुप्रयोगों की जाँच करने का समय नहीं है। यह पता चला कि हमारे पास अभी तक हमारे आवेदन की जांच करने का समय नहीं था, हम Google Play उपयोगकर्ताओं तक नहीं पहुँचे, लेकिन केवल हुआवेई सेलरी में प्रकाशित हुए। और यही कारण था कि हमारे पास केवल Huawei पर बग थे। इस प्रकार, Google Play पर प्रकाशित होने से पहले ही एक महत्वपूर्ण बग का पता लगाना और उसे ठीक करना संभव था।

आगे, मैं आपको बताऊंगा कि Google Play के माध्यम से प्रकाशनों की व्यवस्था कैसे की जाती है, क्योंकि हमारे पास वहाँ उपयोगकर्ताओं की एक बहुत बड़ी हिस्सेदारी है। और Huawei AppGallery में, हमने हाल ही में छोड़ दिया है और अभी भी यह समझने की कोशिश कर रहे हैं कि वहां सब कुछ कैसे व्यवस्थित किया जाता है।

हम Google Play पर सभी उपयोगकर्ताओं को तुरंत प्रकाशित नहीं करते हैं, ताकि किसी प्रकार की यादृच्छिक बग हमारे पूरे दर्शकों को प्रभावित न करें। हम केवल उन सभी परीक्षकों को प्रकाशित करते हैं जो इस तथ्य की सदस्यता लेते हैं कि उनके पास बग हो सकता है, लेकिन वे हमारे परिवर्तन और रिलीज़ प्राप्त करने वाले पहले व्यक्ति होंगे। इसके अलावा, हम केवल पांच प्रतिशत दर्शकों को प्रकाशित करते हैं।



बुधवार को, ड्यूटी पर मौजूद डेवलपर क्रैश-फ्री नई रिलीज़ देख रहा है। हमारे लिए यह महत्वपूर्ण है कि कोई नई दुर्घटना न हो और बहुत पुराने न हों। यदि सब कुछ सामान्य है, तो वह अभी भी उत्पाद मैट्रिक्स की जांच करता है। उदाहरण के लिए, ताकि उसी अवधि की तुलना में आदेशों की संख्या में गिरावट न हो। यदि हमारे उत्पाद मैट्रिक्स और क्रैश-फ्री हैं, तो हम एक और 5%, कुल 10% रोल आउट कर रहे हैं।



गुरुवार को, डेवलपर ऑन ड्यूटी स्टोर में समीक्षाओं की जांच करता है। वास्तव में, वह बुधवार को उन्हें देखता है। सच है, बुधवार को हमारे पास अभी भी एक छोटा दर्शक वर्ग है, एक या दो समीक्षाएँ। लेकिन गुरुवार को रिलीज को जज करने के लिए और समीक्षाएं हैं। 10-15 टुकड़े हो सकते हैं।

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

यदि समीक्षा क्रम में है, तो क्रैश-फ़्री भी सामान्य है और उत्पाद मैट्रिक्स में खराबी नहीं आई है, हम पहले से ही 20% रोल आउट कर रहे हैं।



और इसलिए यह शुक्रवार को शुरू होता है, हमारी रिलीज़ का दिन। तीसरा बिंदु जो मैं बात करना चाहता था वह यह है कि शुक्रवार को हम वर्तमान रिलीज को पूरा करेंगे। हम इसे 20% से तुरंत 100% तक रोल करते हैं। यह एक बहुत बड़ी छलांग और बहुत जोखिम भरा लगता है। लेकिन यह टीम और आपके दर्शकों पर निर्भर करता है।

हमारे दर्शकों का 20% हमें रिलीज की स्थिरता का न्याय करने के लिए एक उच्च संभावना के साथ अनुमति देता है। और अगर 20% तक सब कुछ अच्छा है, और शुक्रवार को हमने कोई समस्या नहीं देखी, तो हम सीधे सौवें स्थान पर जाएंगे।

मैं Google Play पर जीवन हैक का उपयोग करने वाली टीमों को जानता हूं - शायद वह आपकी भी मदद करेगी। आप 100% पर नहीं, बल्कि 99.9% पर रोल आउट कर सकते हैं। यह आपको Google Play पर एक बटन के साथ तत्काल रिलीज को रोकने के लिए छोड़ देगा। और यदि आप 100% रोल आउट करते हैं, तो यह बटन गायब हो जाता है। लेकिन, जैसा कि मैंने कहा, हमारे दर्शकों के बीस प्रतिशत से हम रिलीज की स्थिरता का सही अनुमान लगा सकते हैं। इसलिए, हम शांति से 100% रोल आउट करते हैं, यह हमें अतिरिक्त चरणों से बचाता है। और फिर आपको एक और 0.01% रोल करने की आवश्यकता है।

यह हमारी प्रक्रिया है, इसलिए हम हर हफ्ते की सवारी करते हैं और कोशिश करते हैं कि यह खो न जाए।


उपयोगकर्ता के अच्छे जीवन का समर्थन करने के लिए हमारे पास अन्य कौन से उपकरण हैं? ये फोर्स अपडेट, सॉफ्ट अपडेट और फीचर टॉगल हैं।



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

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



फोर्स अपडेट की मदद के लिए सॉफ्ट अपडेट है। यह Google की एक देशी चीज़ है, जो केवल आपके एप्लिकेशन में एम्बेडेड है और उपयोग को ब्लॉक नहीं करता है। लेकिन वह कहती है - Google Play पर एक अपडेट है, इसे इंस्टॉल करें और आपके पास नया शांत सामान होगा।

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

सॉफ्ट अपडेट ने हमें संस्करणों की पूंछ को बहुत कम करने की अनुमति दी, और यह केवल प्रलेखन के अनुसार लागू किया गया है। यदि आपके पास कई रिलीज़ हैं, तो इसे आज़माएँ।



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

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



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

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



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

लेकिन हम नहीं चाहते कि उपयोगकर्ता का एप्लिकेशन गायब हो। हम उसे आवेदन का उपयोग करने का अवसर देना चाहते हैं, इस तथ्य के बावजूद कि उसके पास अभी भी एक बड़े आकार के साथ टॉगल है। इसलिए, जब हम मोटर बंद करते हैं, तो वाहन को नियंत्रित करने के लिए हमारे पास एक फॉलबैक तंत्र होना चाहिए। इस मामले में, यह एक ऐसा संकर है।



शायद यह विचार करने लायक था कि छत की पुनरावृत्ति। शायद ड्राइवर को ऐसी सीट पर बैठने में असुविधा होगी। लेकिन वह अभी भी एक वाहन चला सकेगा, एप्लिकेशन का उपयोग कर सकेगा, और नहीं चल सकेगा।

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



अब, जैसा कि मैंने पहले ही कहा है, हमारे पास Android और iOS विकास टीमों में से प्रत्येक में 13 लोग हैं। हम एक गेट फ्लो पर काम करते हैं, एक रिपॉजिटरी में, हमारी नियोजित रिलीज प्रक्रिया को सेट करते हैं, हर हफ्ते बाजार और सवारी करने का समय कम करते हैं। हमने हाल ही में Huawei AppGallery जारी की, और अन्य स्टोर देखें। हमने फीचर टॉगल के कारण अपडेट के बिना उपयोगकर्ता एप्लिकेशन को बदलना सीखा। ध्यान देने के लिए आपको धन्यवाद।