रिलीज को कैसे व्यवस्थित करें

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

रिहाई की तैयारी कैसे करें?

एक जिम्मेदार व्यक्ति चुनें

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

कैलेंडर कस्टमाइज़ करें

कॉर्पोरेट कैलेंडर में एक तिथि निर्धारित करें और सुनिश्चित करें कि सभी हितधारक जानते हैं।

विकी पर तालिका बनाओ

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

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

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

आंतरिक घोषणा

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

रिलीज के दौरान

रिलीज ब्रंच बनाएं

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

अधिसूचना भेजें

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

टैग करें

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

खुद रिलीज करें

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

एक बटन रिलीज

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

अगर सब कुछ योजना के अनुसार गलत हुआ

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

रिलीज के बाद

निगरानी करना

त्रुटियों, सर्वर लोड की निगरानी करना न भूलें। यह KPI पर भी ध्यान देने योग्य है: यदि आपने एक रिलीज़ किया और आपका DAU गिरा, तो हो सकता है कि कुछ काम नहीं कर रहा हो और साथ ही निगरानी उपकरण स्वयं भी टूट गए हों। कोई भी संदिग्ध गतिविधि जांचने लायक है।

सफलता और विफलता की रिपोर्ट करें

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

एक पूर्वव्यापी संचालन करने के लिए

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

पिज्जा ऑर्डर करें और जश्न मनाएं

इस तरह की सभाओं के दौरान, सिर्फ सहकर्मी मित्र और कॉमरेड बन जाते हैं। और इसका मतलब है कि अगली लड़ाई में, दोस्त आपको निराश नहीं करेंगे।

अगली रिलीज की तैयारी शुरू करें

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

अन्य कंपनियां कैसे जारी करती हैं?

Spotify

स्पॉटिफाई अक्सर रिलीज़ ट्रेन के अभ्यास के आधार पर रिलीज़ होगी। जैसा कि इस अभ्यास के नाम से संकेत मिलता है, रिलीज एक ट्रेन के समान है: जिस किसी ने अपना काम पूरा नहीं किया है वह अगली रिलीज की प्रतीक्षा कर रहा है। इस दृष्टिकोण के फायदे यह हैं कि एक विफल टीम उत्पाद वितरण में देरी नहीं करती है और अधूरे कार्यों को आगे बढ़ाने की कोशिश नहीं करती है। और नतीजतन, रात में देवों के पास अपने फोन फटे नहीं होते हैं, और ड्यूटी टीम सुबह आंखों के नीचे बैग के साथ काम पर दिखाई नहीं देती है। बेशक, यह दृष्टिकोण एक आउटसोर्सिंग कंपनी के लिए काम नहीं करेगा: ग्राहक अधूरे काम के लिए भुगतान नहीं करेगा। खुलकर: मुझे कंपनी की संस्कृति पसंद है, मैं आपको एक वीडियो देखने की सलाह देता हूं (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) यह कैसे काम करता है।

बुकिंग

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