एकाधिक कोड शाखाओं और प्रसवों का प्रबंधन

Question

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

हाल ही में, हमने कई नए ग्राहकों को अधिग्रहित कर लिया है और एक नई समस्या उत्पन्न हुई है: मुख्य शाखा आम तौर पर कई अलग-अलग ग्राहक विशिष्ट समस्याओं का समाधान करेगी (और सभी ग्राहक सभी परिवर्तनों को नहीं चाहते हैं, लेकिन सभी ग्राहक चाहते हैं बल्कि चेरी-फिक्स फिक्स और फीचर्स को पसंद करते हैं।

क्या आपके पास उस स्थिति के साथ कोई अनुभव है, और परीक्षण और कार्य (हमारे मासिक रिलीज परीक्षणों में कंप्यूटर समय के लगभग 3 दिन लगते हैं) के बिना इसे व्यावहारिक रूप से कैसे संभालना है? और संस्करण नियंत्रण के अनुसार, आप कैसे प्रबंधित करते हैं (मुझे लगता है कि सीवी को अंत में जाना होगा ...)?

Answer 1

इस स्थिति में सीवीएस का उपयोग करना संभव है (मैं आपको सलाह देता हूं कि आप एसवीएन जैसे अन्य विकल्पों पर नज़र डालें)।

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

यह दृष्टिकोण हालांकि (विलय और भवन) के बहुत सारे कॉन्फ़िगरेशन प्रबंधन प्रयास लेता है, इसलिए हो सकता है कि आप एक विशिष्ट व्यक्ति को कार्य कार्यों को संभालने के लिए चाहते हों।

संपादित करें:

Additionaly, आप (यदि पहले से ही नहीं है) चाहिए एक बग ट्रैकर प्रणाली है, जिसमें आप आप पर काम कर रहे ग्राहक/शाखा दस्तावेज़ चाहिए।

Answer 2

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

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

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

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

यहां तक ​​कि सर्वश्रेष्ठ संस्करण नियंत्रण प्रणाली के साथ भी (मेरे लिए, यह git होगा), आप फैन-आउट को हल नहीं कर सकते हैं अगर आप सभी को एक ही दिशा में खींच नहीं सकते हैं (सिवाय इसके कि, बेशक, आप वास्तव में प्रत्येक ग्राहक को प्लग-इन में विभाजित कर सकते हैं)।

Answer 3

हमारे पास एक (काफी विशेषज्ञ) उत्पाद और एकाधिक (लेकिन केवल सैकड़ों का क्रम) ग्राहकों का एक समान सेटअप है, जो सभी अपनी पालतू सुविधा चाहते हैं।

जहां तक ​​मैं देख सकता हूँ कि आप या तो 'ऑफ-द-शेल्फ' मार्ग जहाँ आपके उत्पाद गैर ग्राहक विशिष्ट है, और आप उत्पाद की भलाई के लिए कर रहे हैं जोड़ने के किसी भी सुविधाओं (कम से संभवतः ग्राहकों की नीचे जा सकता है निवेदन); या आप bespoke, परामर्श मार्ग नीचे जाते हैं जहां हर ग्राहक के पास उत्पाद का अपना अनूठा संस्करण होता है।

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

छिपाने की सुविधा आसान है, एकाधिक समवर्ती संस्करणों को बनाए रखना दुःस्वप्न है!

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

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

Answer 4

केवल सिर/मुख्य ट्रंक का समर्थन करें, जब तक कि कोई ऐसी शाखा न हो जिसमें बग फिक्स/सुविधा हो जो मुख्य रेखा में मौजूद न हो।

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

ऐसा मत करो।

फर्म बनें।