रिहाई प्रबंधन

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

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

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

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

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

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

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

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

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