ग्राहक-विशिष्ट सॉफ़्टवेयर पैच को संभालने का एक यथार्थवादी तरीका क्या है?

Question

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

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

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

Comments

यदि आप उपयोग कर रहे थे hgया gitमैं आपको सुझाव दे सकता हूं कि आप पैच क्यू ( मर्क्यूरियल क्यूज़ एक्सटेंशन या स्टैक्ड गिट ) का उपयोग कर रहे हैं, लेकिन मुझे नहीं पता कि क्या टीएफएस में भी ऐसा ही कुछ है।

— मार्क बूथ

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

— विम्स

एक व्यावसायिक समाधान होगा: यह मत करो।

— जेएफओ

@JeffO अच्छा कॉल =) किसी भी मामले में, क्या कोई तरीका है जिससे आप इसे डेटा चालित रनटाइम स्विच बना सकते हैं?

— पैट्रिक ह्यूजेस

@ जॉन - क्षमा करें, मुझे नहीं पता, लेकिन अगर आपके पास स्रोत पैच हैं, तो आपकी बिल्ड प्रणाली को परीक्षणों को स्वचालित करने में सक्षम होना चाहिए, साथ ही प्रति ग्राहक पैच को बाहर रखने का svnमतलब है कि वे आपके सामान्य वर्कफ़्लो को अव्यवस्थित नहीं करते हैं। यदि पैच कतारें ऐसी लगती हैं कि वे उपयोगी हो सकती हैं, तो आप उन्हें git-svn या hgsubversion का उपयोग करके आज़मा सकते हैं । एक DVCS सामने के छोर का उपयोग कर एक मुश्किल वर्कफ़्लो को सुचारू करने के लिए, svnयहां तक ​​कि लोगों को DVCS होलसेल में जाने पर विचार करने के लिए प्रोत्साहित किया जा सकता है, अन्य सभी लाभ प्राप्त करने के लिए।

— मार्क बूथ

Answer 1

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

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

Answer 2

ऐसा लगता है कि कुंजी "दृश्यमान" है - एक अलग कोड शाखा बिल्कुल नहीं होने के बारे में क्या है, बल्कि एक कॉन्फ़िगरेशन विकल्प जो व्यवहार को बदलता है?

Comments

यह सरल अनुकूलन के लिए काम कर सकता है, लेकिन अधिक जटिल उत्पाद सभी ग्राहकों के लिए उत्पाद को अधिक अजीब और अस्थिर बना सकते हैं।

— FrustratedWithFormsDesigner

एकल ग्राहकों के लिए @FrustratedWithFormsDesigner जटिल अनुकूलन उत्पाद प्रबंधन और डिजाइन में घोर लापरवाही का प्रतिनिधित्व करते हैं। किसी भी उत्पाद के लिए एकल ग्राहक के लिए एक अलग शाखा की आवश्यकता वाले किसी भी समाधान को उत्पाद के मालिक की ओर से सभी ग्राहकों की जरूरतों और खराब रद्दीकरण को पूरा करने के लिए उत्पाद में एक अपर्याप्त अपर्याप्तता का प्रतिनिधित्व करता है।

— maple_shaft

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

— स्टीव हिल

@maple_shaft - लेकिन क्या आपने सवाल पूछा "क्या आपने कभी अंतर्राष्ट्रीयकरण को लागू करने के लिए कोड शाखा का उपयोग किया है"?

— Psr

@maple_shaft - मैं मजाक कर रहा था, लेकिन, वास्तव में, यह मेरी बात थी, अंतर्राष्ट्रीयकरण को संभालने के लिए शाखाओं का उपयोग करके ग्राहक विशिष्ट शाखाओं के रूप में कम से कम उतना ही बुरा है। यह समझ में नहीं आता है कि आप ऐसी जगह काम नहीं करना चाहते। यह मेरे लिए विषय से हटकर है।

— Psr

Answer 3

क्या आप इसे एक छोटी अवधि या लंबी अवधि की चीज के रूप में देखते हैं? तथ्य यह है कि व्यवसाय ने पहले से ही इस ग्राहक को समायोजित करने का फैसला किया है, इसलिए यह पहले से ही व्यवसायिक प्रथाओं द्वारा प्राथमिक रूप से हल किया जाना है (अतिरिक्त लागत को स्वीकार करना / लागत के लिए ग्राहक को चार्ज करना)।

यदि दीर्घकालिक है तो आप शायद बचत देखेंगे अगर आप सॉफ्टवेयर को आसानी से समायोजित कर सकते हैं ताकि ग्राहकों को कॉन्फ़िगरेशन (या सेटअप आदि) के माध्यम से आसानी से समायोजित किया जा सके।

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

कहानी संक्षिप्त में। लंबी अवधि के लिए यह तकनीकी रूप से ठीक है, इसके साथ लघु अवधि का सौदा।

बेशक वहाँ एक बिंदु है जहाँ यह एक सिक्का टॉस है। यदि आप उस बिंदु पर हैं तो मैं वही करूंगा जो डेवलपर्स पसंद करते हैं।

Answer 4

हम तोड़फोड़ का भी उपयोग करते हैं - और हम सटीक ऐसे परिदृश्य में आते हैं।

यहाँ कुछ महत्वपूर्ण बिंदु याद रखने योग्य हैं:

1. हालांकि यह आवश्यक है कि ग्राहकों के लिए विशिष्ट शाखाओं से बचना चाहिए क्योंकि आवश्यकता को कम से कम किया जाना चाहिए; हमेशा पूछें कि क्या इस समाधान को सामान्य बनाना संभव है जो सभी के लिए काम कर सकता है।

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

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

4. हमेशा, किसी भी परिस्थिति में, आपको ग्राहक विशिष्ट परिवर्तनों को शाखा या ट्रंक जारी करने के लिए वापस नहीं धकेलना चाहिए। हालांकि, आदर्श रूप से किसी को इस तरह से काम को सामान्य बनाने की कोशिश करनी चाहिए कि ऐसे ग्राहक विशिष्ट काम को कम रखा जाए।

मैंने इन विचारों को एक साथ दिखाने की कोशिश की है :

Answer 5

अपने कोड में एक्सटेंशन तंत्र की शुरुआत कैसे करें?

आपके मुख्य कोड में है:

class Foo
{
}

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

class FooForABC : Foo
{
}

FooForABC Foo के समान व्यवहार को लागू करता है लेकिन ABC को जिस विशिष्ट व्यवहार की आवश्यकता होती है उसे प्रदान करने के लिए आवश्यक कार्यों को ओवरराइड करता है। तकनीक को इतना लचीला होना चाहिए कि आपको किसी भी परिदृश्य का समर्थन करने की आवश्यकता हो।