2009-09-07 11 views
5

मैं संस्करण नियंत्रण के विषय पर सभी प्रश्न यहां पढ़ रहा हूं, लेकिन मुझे नहीं लगता कि मुझे ऐसा परिदृश्य मिला जो मेरे जैसा दिखता है।संस्करण नियंत्रण "सर्वोत्तम अभ्यास"

परिदृश्य है:

हम एक मध्यम/बड़े आकार वेब अनुप्रयोग है कि (कम से कम यह होना चाहिए) एक कोर है कि सभी ग्राहकों के लिए तैनात किया जाता है मिल गया है। जब हम ग्राहकों को आवेदन के डेमो बनाते हैं तो लगभग सभी लेआउट में परिवर्तन, या लिस्टिंग में डेटा, या डेटा एंट्री फॉर्मों आदि में फ़ील्ड का अनुरोध करते हैं ... लगभग सभी परिवर्तनों में शेष में परिवर्तन की आवश्यकता होती है " परतों "आवेदन के।

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

कभी-कभी, क्लाइंट से अनुरोध भी सभी ग्राहकों को वितरित करने के लिए कोर में शामिल हो जाता है।

तो मेरा सवाल यह है: क्या शाखाएं एप्लिकेशन के अनुकूलित क्लाइंट संस्करणों में परिवर्तन को अलग करने का सबसे अच्छा तरीका हैं? जब भी कोई नया ग्राहक अनुकूलन के लिए पूछता है तो क्या हमें शाखा बनाना चाहिए? या क्या हम इसे एक अलग भंडार के साथ एक पूरी तरह से अलग परियोजना के रूप में मानना ​​चाहिए?

सभी अलग-अलग संस्करणों को बनाए रखना होगा, और जैसा कि मैंने सुना है कि शाखाएं "अस्थायी" हैं, यदि शाखाकरण सबसे अच्छा समाधान है तो मुझे संदेह है।

प्रतिक्रिया के लिए धन्यवाद।

एंटोनियो डायस

+0

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

उत्तर

4

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

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

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

प्रत्येक ग्राहक के लिए अलग-अलग भंडार पूरी तरह गलत काम करने की तरह लगता है, क्योंकि इसके परिणामस्वरूप भंडारों के बीच सामान्य कोड का डुप्लिकेशंस होगा।

+3

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

0

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

cvs tag -r MY_TAG -b MY_BRANCH 

एक शाखा टैग से एक शाखा प्रारंभ करने में पर्याप्त होगा।

उन शाखाओं को आपके वर्तमान विकास से शुरू होने वाले प्रत्येक यूएटी (उपयोगकर्ता स्वीकृति परीक्षण) चक्र के लिए किया जाना चाहिए।इसके बाद आप कर सकते हैं:

  • या तो इस नई शाखा
  • या सीधे में पिछले एक शाखा एक ग्राहक के लिए एक पिछले प्रदर्शन के लिए किए गए कार्य की सामग्री मर्ज करने के लिए नई शाखा में अनुकूलन को फिर से लागू करने की कोशिश।
  • उन शाखाओं को छोड़ दें जैसे यूएटी चक्र किया जाता है। उन्हें संशोधित नहीं किया जाएगा लेकिन अगले चक्र के लिए अगली शाखाओं के संदर्भ के रूप में कार्य कर सकते हैं।

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

4

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

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

यदि आप नए क्लाइंट जोड़ते हैं तो आप इस शाखा-प्रति-क्लाइंट रणनीति को जारी रखते हैं तो चीजें बदतर हो जाएंगी।

+0

हाँ, लेकिन यह एक "पुराना" ऐप (एचटीएमएल/एएसपी/वीबी 6) है और अब "चीज़" को दोबारा असंभव करना असंभव है .. परिवर्तन केवल अनुकूलित पृष्ठों का एक सेट हो सकता है (जैसे विभिन्न छवियां, या टेक्स्ट लेबल्स या कुछ "तुच्छ")। मैं वर्जन कंट्रोल सिस्टम में मानक संस्करण और यह नया संस्करण कैसे रखूं? –

+0

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

+0

हाँ, मुझे पता है, लेकिन रिफैक्टर की लागत वास्तव में आवश्यक काम के संदर्भ में नहीं बल्कि यह भी है क्योंकि ऐप को बनाए रखने वाले केवल दो लोग हैं, क्योंकि हर समय नया अनुरोध आ रहा है और बहुत सारी बग ठीक हो रही हैं। ऐप पहले से ही अनुकूलन की एक निश्चित डिग्री (मुख्य रूप से डिजाइन में) की अनुमति देता है लेकिन मेरी समस्या यह है कि अगर कोई नया "मॉड्यूल" (पृष्ठों का एक समूह और कुछ कोड) मांगता है तो मैं इन नए पृष्ठों को वीसीएस में कहां रखूं? अन्य सभी मानक पृष्ठों के साथ? क्या मैं इन परिवर्तनों के लिए सिर्फ एक नया भंडार (प्रोजेक्ट) बना सकता हूं और एकीकृत करने के लिए मैं कोर मॉड्यूल खींचता हूं और नया जोड़ता हूं? –

3

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

+0

हाँ, मुझे पता है कि संस्करण नियंत्रण वितरण के लिए नहीं है। एप्लिकेशन वेब-आधारित है, और वेब पेजों में कस्टमाइज़ेशन बदल सकता है, या bussiness तर्क, या डीबी में नई टेबल .. मैं इन सभी परिवर्तनों को कैसे प्रबंधित कर सकता हूं, संस्करण नियंत्रण प्रणाली में, यह सुनिश्चित कर रहा हूं कि एक बदलाव किया गया हो एक ग्राहक के लिए किसी अन्य ग्राहक को प्रचार नहीं करता है (जब तक कि इसका मतलब न हो।)? –

+0

ठीक है, उस मामले में मुझे लगता है कि उनमें से प्रत्येक एक अलग परियोजना होगी (हालांकि यह छोटा हो सकता है), और उसके पास ट्रंक, शाखा और टैग का अपना सेट होना चाहिए। आप उन परियोजनाओं में से प्रत्येक के लिए निर्देशिका बना सकते हैं। – phunehehe

1

सबसे पहले, शाखाओं को गले लगाएं और जानें कि अपने संस्करण नियंत्रण प्रणाली का सही तरीके से उपयोग कैसे करें।

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

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

घटकों को तोड़ना और उप-परियोजनाएं संभव है? कुछ मुख्य क्षेत्र अक्सर बदल नहीं सकते हैं और निर्माण में जोड़ा जा सकता है (जैसे तृतीय पक्ष जार)।

या आपके पास अपना मूल निर्माण/इंस्टॉल हो सकता है और फिर अनुकूलन पर परत हो सकती है। कस्टम फाइलों को ओवरले करें और/या बेस फाइलों को संशोधित करें।

2
Feature Branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging. 

दान Bodart - Martin Fowler

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

+1

"[यू] शाखाओं के बजाए बयान अगर गाते हैं ... इस तथ्य के लिए एक काम है [तथ्य] कि आपका संस्करण नियंत्रण उपकरण ऐसा नहीं कर रहा है जो इसका मतलब है।" - जोएल स्पॉस्की http://www.joelonsoftware.com/items/2010/03/17.html – jammycakes

+0

हां: लेकिन यह विपरीत मामले का एक उदाहरण प्रतीत होता है। या क्या आपको लगता है कि अगर स्रोत कोड में बयान शाखाओं द्वारा प्रतिस्थापित किया जाना चाहिए? – soru

+0

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