2009-05-31 10 views
6

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

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

लेकिन इस मामले में, मैं भंडार के लिए ज़िम्मेदार हूं, और इस तरह की चीज मेरे लिए पूरी तरह से नई है।

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

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

उदाहरण के लिए, मान लीजिए कि मैं प्रो और एंटरप्राइज़ संस्करणों के लिए एक नई सुविधा विकसित करना चाहता हूं, लेकिन मैं उस सुविधा को डेमो संस्करण से बाहर करना चाहता हूं। मैं इसे कैसे पूरा करूं?

मेरे दिन-प्रतिदिन के विकास में, मुझे यह भी लगता है कि मुझे अपने विकास स्नैपशॉट को शाखा से शाखा (या वापस ट्रंक) में स्विच करने की आवश्यकता है क्योंकि मैं काम करता हूं। ऐसा करने का सबसे अच्छा तरीका क्या है, इस तरह से भ्रम को कम करता है?

आप अन्य रणनीतियां, दिशानिर्देश और सुझाव क्या सुझाव देते हैं?


अद्यतन:

ठीक है, सब ठीक तो।

ऐसा लगता है कि शाखाकरण बिल्कुल सही रणनीति नहीं है। तो मैंने "शाखाकरण" फोकस को हटाने के लिए प्रश्न का शीर्षक बदल दिया है, और मैं सवाल को विस्तृत कर रहा हूं।

मैं अपने अन्य विकल्पों में से कुछ लगता है कर रहे हैं:

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

2) मैं निर्भरता इंजेक्शन का उपयोग कर सकता हूं। लेकिन आम तौर पर, मुझे इससे नफरत है (क्योंकि यह स्रोत कोड से लॉजिक को कॉन्फ़िगरेशन फाइलों में ले जाता है, जिससे परियोजना को ग्रोक करना मुश्किल हो जाता है)। और फिर भी, मैं अभी भी पूर्ण ऐप वितरित कर रहा हूं और रनटाइम पर सुविधाओं का चयन कर रहा हूं। यदि संभव हो, तो मैं उपयोगकर्ताओं को डेमो उपयोगकर्ताओं के लिए एंटरप्राइज़ संस्करण बाइनरी वितरित नहीं करना चाहूंगा।

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

4) मैं निर्माण करने के लिए एएनटी का उपयोग कर रहा हूं।क्या एएनटी के लिए बिल्ड-टाइम निर्भरता इंजेक्शन की तरह कुछ है?

उत्तर

2

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

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

एक विकल्प के रूप में आप कई जार वितरित कर सकते हैं, प्रत्येक घटक के लिए एक लाइसेंस प्राप्त है और केवल लाइसेंस प्राप्त करने वाले वर्गों को लोड करने की अनुमति देता है। इसे प्राप्त करने के लिए आपको कक्षा लोडर में जोड़ना होगा।

2

क्या आप इसे सबवर्जन के माध्यम से करना चाहते हैं? मैं अलग-अलग (एक प्रति रिलीज शाखा जैसे v1.0, v2.0 इत्यादि) को जारी रखने के लिए सबवर्जन का उपयोग करूंगा लेकिन मैं से कोडबेस से अलग संस्करण (परीक्षण/प्रो इत्यादि) बनाने पर विचार करूंगा।

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

स्विचिंग के लिए, आप बस चेक-आउट कोडबेस बनाए रख सकते हैं, और अलग-अलग संस्करणों को चेकआउट करने के लिए svn switch का उपयोग कर सकते हैं। यह प्रत्येक स्विच के लिए नए चेकआउट करने से बहुत कम समय लेने वाला है।

+0

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

1

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

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

मैं ब्रायन की सिफारिश को दूसरी बार कोड आधार पर रिलीज़ को अलग करने के लिए सिफारिश करता हूं।

संबंधित मुद्दे