सामान्य रिलीज बनाम रखरखाव रिलीज पर नीति?

Question

मेरी कंपनी समर्थन के लिए भुगतान करने वाले बड़े संगठनों पर साइट पर स्थापित एक एप्लिकेशन के संदर्भ में "सामान्य" रिलीज बनाम रखरखाव रिलीज के सवाल से जूझ रही है। सबसे पहले मुझे अपनी शर्तों को परिभाषित करने दें:

• कल्पना कीजिए कि हमने उत्पाद के संस्करण 1.0, 1.1 और 1.2 जारी किए हैं। ये हैं जिन्हें मैं "सामान्य" रिलीज करता हूं, यानी वे विकास की मुख्य शाखा से अगली रिलीज हैं, जिसमें सभी नवीनतम और सबसे बड़े बग फिक्स और एन्हांसमेंट (संभवतः प्रत्येक रिलीज के दसियों) शामिल हैं।
• अब कल्पना करें कि 1.0 पर कुछ बड़ेशॉट ग्राहक एक शो-स्टॉपिंग मुद्दे की रिपोर्ट करते हैं जो किसी के सामने नहीं आया है। समस्या अभी भी 1.2 में मौजूद है, और दुर्भाग्यवश 1.3 कई हफ्तों या महीनों के लिए नहीं है। इसलिए हम 1.0.1 "रखरखाव" रिलीज बनाने के लिए 1.0 पर हमारे कोड को ब्रांच करते हैं, जिसमें केवल एक ही समस्या है जो समस्या को हल करता है।

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

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

समस्या यह है कि है

• यह अंततः उन ग्राहकों को भविष्य में अपग्रेड करने की प्रक्रिया को जटिल बनाता है, क्योंकि उनकी स्थापना प्रत्येक अन्य 1.0 ग्राहक से काफी अलग है (अगर उनके रखरखाव को किसी भी तरह बदल दिया गया है तो उनके डेटाबेस को अपग्रेड करना विशेष रूप से जटिल है)

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

स्पष्टीकरण: बग-फ्री सॉफ़्टवेयर लिखना कुल समाधान नहीं है, क्योंकि उपर्युक्त संदर्भ में "समस्या" बाहरी प्रणाली के व्यवहार में एक अप्रत्याशित परिवर्तन हो सकता है जिस पर हमारा उत्पाद निर्भर करता है।

Answer 1

हम अपने ग्राहकों के लिए केवल एक ही रिलीज बनाते हैं, और हम दैनिक निर्माण और इकाई परीक्षण करते हैं (आप तुम दोनों है, नहीं करते ?)

इन दो हम काफी बाहर धक्का कर सकते हैं

हमारे कोड जितनी बार चाहें उतनी बार, इसलिए रखरखाव रिलीज या सामान्य रिलीज के बारे में चिंता करने की कोई आवश्यकता नहीं है। केवल एक प्रतिलिपि है जिसका उपयोग करने लायक है, और यह नवीनतम प्रति है।

संपादित करें: यह स्थिति "की बात आती है OMG हमारे सुविधा आधा रास्ता है लेकिन हम अभी भी है और अब इसे जारी करने की जरूरत है हाँ मैं अब मतलब! "हम क्या करेंगे कि हम केवल नई सुविधा को टैग करेंगे (preprocessor directive का उपयोग करके) और सुनिश्चित करें कि निर्माण के दौरान, टैग के अंदर सभी कोडों को आसानी से टिप्पणी की जाती है।

Answer 2

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

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

मुझे यकीन नहीं है कि आप इस दुख को बेहतर बनाने के लिए बहुत कुछ कर सकते हैं।

Answer 3

दुर्भाग्यवश, यह आपके द्वारा पहले ग्राहक के साथ किसी भी अनुबंध पर हस्ताक्षर करने से पहले तय करने की आवश्यकता है। यदि यह अनुबंध में नहीं है, तो यह अस्तित्व में नहीं है।

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

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

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

Answer 4

हमारे पास दोनों रखरखाव और सामान्य रिलीज हैं।

मान लीजिए कि हम 5.5 रिलीज पर काम कर रहे हैं और ग्राहक को पिछले संस्करण में कुछ समस्याएं 5.4.0.1 में मिल सकती हैं, हम उन्हें 5.4.1.0 में समाधान प्रदान करेंगे और हमारे वर्तमान रिलीज यानी 5.5 में संशोधन भी करेंगे इस तरह से हम

Answer 5

निम्नलिखित कार्यप्रवाह आप (लेकिन YMMV) मदद कर सकता है वर्ष रिलीज में ग्राहकों के लिए मौजूदा रिलीज में पिछले मुद्दों को बंद करने के साथ ही एक नया किट प्रदान की कोशिश:

1. एक बनाएं विषय शाखा बगफिक्स के लिए, इसे शुरुआती बिंदु पर बंद कर दें (ई .g। 1.0 रिलीज), नामित उदा। 'foo-bugfix'
2. संस्करण के लिए रखरखाव रिलीज के लिए नई शाखा बनाएं उदा। 1.0, यदि यह अभी तक अस्तित्व में नहीं है, और यदि इस संस्करण में बग मौजूद है, नाम ई।, जी। 'maintain-1.0'
3. बगफिक्स शाखा को रखरखाव शाखा में मर्ज करें, यदि कोई हो तो संघर्ष हल करें।
4. यदि आवश्यक हो तो संस्करण संख्या संशोधित करें। नई रखरखाव रिलीज टैग करें, उदा। 1.0 '।1 केवल परियोजना के अंतिम संस्करण के लिए '(maint' या 'रखरखाव' अन्य संस्करणों है कि आप ही आप रखरखाव रिलीज करना जैसे नामित शाखा पर) आमतौर पर

समर्थन करना चाहते हैं के लिए

दोहराएँ 2-4 '। हालांकि, यह अच्छा अभ्यास है, मुझे लगता है, अगर आपको प्रभावित होने वाले सभी संस्करणों पर इसे ठीक करने के लिए गंभीर बग (उदा। गंभीर सुरक्षा बग) मिलती है (शायद उन संस्करणों को सीमित कर दें जो बहुत पुराने नहीं हैं/अभी भी व्यापक रूप से उपयोग किए जाते हैं)।

HTH

Answer 6

क्या मेरा सुझाव है हमेशा कम से कम नवीनतम बिंदु रिलीज की कोशिश करने के लिए ग्राहक को पूछने के लिए है: यह है कि अगर उनकी समस्या का हल देखने के लिए 1.0 से 1.1 करने के लिए कदम। पहले सवाल पूछा।

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

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

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

यह माइक्रोसॉफ्ट की सर्विस पैक विधि से तुलना करता है: हॉटफिक्सेस को अक्सर रिलीज़ करें और फिर सर्विस पैक (-> पॉइंट रिलीज) में उन्हें एक साथ इकट्ठा करें। विस्तृत रिलीज से पहले हॉटफिक्स को अक्सर समस्याओं का सामना करने वाले ग्राहकों के साथ परीक्षण किया जाता है, पैच ठीक करने के लिए बाहर है।

जो आप निश्चित रूप से टालना चाहते हैं वह "1.0.1-ग्राहक ए" और "1.0.1-ग्राहक बी" है, आप जटिलता और रखरखाव नरक को आमंत्रित कर रहे हैं।

आम तौर पर आपको हमेशा अपने पैच को अपनी मुख्य रेखा में वापस विलय करना चाहिए। यदि आपका ग्राहक आपके नवीनतम संस्करण के लिए आपके पैच बनाने में मदद कर रहा है, तो उसे गले लगाओ।

Answer 7

मैं Version Control for Multiple Agile Teams पढ़ने और विशेष रूप से Release branches सेक्शन पढ़ने का सुझाव देता हूं (एन टीमों के लिए भी काम करता है 1 टीम के लिए भी काम करता है)।

जो मैंने अभी तक विभिन्न उत्तरों और टिप्पणियों में पढ़ा है, उससे आपको कुछ अच्छी सलाह मिल सकती है।