2008-11-17 16 views
18

हमारे पास एक ग्राहक है (जिसके पास एक ग्राहक है, जिसके पास ग्राहक है) जो कोड कोड (PHP में) में परिवर्तन अनुरोधों के साथ हमें पागल कर रहा है। हमारी पहली प्रतिक्रिया केवल एसवीएन में एक मुख्य ट्रंक में काम करना था, लेकिन ग्राहक अक्सर वापस आते हैं और अनुरोध करते हैं कि एक निश्चित परिवर्तन को लाइव सर्वर ASAP पर धक्का दिया जाना चाहिए। दूसरी ओर, अन्य परिवर्तन अचानक प्राथमिकता में कम हो जाते हैं, जो मूल रूप से अन्य परिवर्तनों (समूह) के साथ समूहित हुआ था।शाखाएं?

हम प्रत्येक परिवर्तन अनुरोध के लिए शाखा का उपयोग करने के बारे में सोच रहे हैं। क्या यह पागल है? अन्य समाधान क्या काम कर सकते हैं?

धन्यवाद!

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

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

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

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

अंतिम संपादन (शायद): महीने बाद, यह प्रणाली अभी भी हमारे लिए काम कर रही है। हम हर टिकट के लिए शाखाएं बनाते हैं और शायद ही कभी समस्याएं होती हैं। दूसरी ओर, हम चीजों को जहाँ तक लोगों पर क्या काम कर रहे हैं के रूप में अलग रखने के लिए कोशिश करते हैं ...

दो साल बाद: अब हम GIT उपयोग करते हैं, और अब इस प्रणाली वास्तव में काफी उचित है।

+0

ऐसा नहीं है कि अब हमारे पास गिट क्यों है? –

+0

@Quintin Par, समस्या समान है कि आप गिट (जो हम अभी हैं) या एसवीएन (जैसा कि हम थे) का उपयोग कर रहे हैं। प्रश्न यह है कि टीम/क्लाइंट के लिए शाखाएं कैसे व्यवस्थित करें। –

+1

प्रत्येक छोटे बदलाव के लिए शाखाएं, भले ही आपके पास परिवर्तन अनुरोध या टिकट हों, या यदि आप घर पर अपने स्वयं के प्रोजेक्ट पर काम कर रहे हैं, तो प्रतिबद्धता-गठबंधन (शाखा में) को गठबंधन करने और प्रतिबद्ध करने का एक शानदार तरीका है (मर्ज करें) -working-code-only (ट्रंक में)। साथ ही, ये दो पैटर्न संयुक्त ट्रंक लॉग को साफ रखते हैं लेकिन शाखा लॉग में विस्तृत जानकारी प्रदान करते हैं। – clacke

उत्तर

3

प्रत्येक परिवर्तन अनुरोध के लिए एक शाखा ओवरकिल की तरह लगता है और शायद बाद में कुछ परेशानी हो सकती है।

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

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

+1

इससे उन्हें पैसे मिलते हैं और उन्हें धीमा कर देते हैं। मैं उन्हें ठीक क्यों करना चाहूंगा? अपनी खुद की संवेदना के लिए? यही कारण है कि मेरे पास तकनीक है, और जब यह पर्याप्त नहीं है, तो मेरे पास ज़ेन ध्यान भी है। –

+0

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

+0

हालांकि मैं इसे सबसे अच्छे उत्तर के रूप में छोड़ रहा हूं (इसका क्या अर्थ है?), हम वास्तव में सभी परिवर्तनों के लिए शाखाओं का उपयोग करने के लिए गए हैं और परिणाम काफी अच्छे हैं। –

10

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

जब आप कार्यों के साथ गंदे नहीं होते हैं तो नई विकास शाखा में काम करें।

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

इस तरह से आपके ग्राहक का वितरण अपनी दुनिया में है, आपका नया विकास जारी है (और जब भी आपको इसकी आवश्यकता हो तो विलय किया जा सकता है) और आपका रखरखाव भी कब्जा कर लिया जाता है।

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

+0

मुझे यह जवाब बहुत पसंद है। मैं यह देखने के लिए उत्सुक हूं कि अन्य चोटी किसके साथ आती है। धन्यवाद! –

+0

ठीक है। मदद करने में खुशी। कई प्रतिक्रियाएं प्राप्त करने के लिए हमेशा अच्छा होता है और यह पता लगाता है कि आपके लिए सबसे अच्छा क्या काम करता है! –

+0

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

3

प्रति परिवर्तन अनुरोध शाखा, अतिरिक्त प्रबंधन के लिए ग्राहक की लागत में इसी वृद्धि के साथ, इस समस्या के लिए एक अच्छा दृष्टिकोण है।

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

यह वास्तव में एससीएम प्रणाली अज्ञेयवादी है - लेकिन सबवर्सन निश्चित रूप से आवश्यकतानुसार कर सकता है।

+0

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

+0

और अब, बहुत बाद में, मुझे लगता है कि आप सही हैं ... लेकिन यह व्यक्तिपरक है, मुझे लगता है। –

19

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

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

तो एकल-सुविधा का निर्माण करना और फिर चेरी-पिकिंग करना आपके लिए समाधान हो सकता है।

+0

दिलचस्प। हमें जीआईटी की जांच करनी होगी। वास्तव में यहां प्रश्न पोस्ट करने से पहले चेरी-पिकिंग शब्द हमारी चर्चाओं में पहले ही आया था। धन्यवाद! –

+1

इसके अलावा सबवर्जन चेरी-पिकिंग का समर्थन करता है: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.cherrypicking मैं जीआईटी के साथ एसवीएन चेरीपिकिंग कार्यान्वयन की तुलना नहीं कर सकता क्योंकि मैं एक जीआईटी उपयोगकर्ता नहीं हूं :) –

+0

हाँ, उम्मीद है कि यह एसवीएन में चेरी पिकिंग नहीं किया जा सकता है। मैंने अभी तक जीआईटी की कोशिश नहीं की है, इसलिए मुझे इसके फायदे नहीं पता हैं। –

2

शाखा प्रति परीक्षण, परिवर्तन काम कर रहा है।
टैग प्रति संस्करण रिलीज।
ट्रंक में विकसित करें।
दोहराना।

:)

+0

टैग वास्तव में शाखा नहीं हैं? –

+0

कम से कम विचलन के तहत, वे मूल रूप से हुड के नीचे समान होते हैं - मुख्य अंतर यह है कि उन्हें कैसे देखा जाता है (किसी विशेष समय पर एक स्नैपशॉट बनाम विकास की शाखा) –

+0

धन्यवाद, टिम और एडम दोनों। –

0

जब एक परियोजना के "लाइव" शाखा में तेजी से बदलाव के बहुत कुछ कर, आप एक ठोस कोड समीक्षा प्रक्रिया यह तोड़ने की संभावना को कम करने के लिए की आवश्यकता है। चेक-इन करने से पहले कोड समीक्षा की जानी चाहिए; और उस शाखा से मूल विकास को दूर रखें।

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

1

मेरे कार्यस्थल हम निम्नलिखित प्रणाली है:

  • स्थिर शाखा: यह जहां परीक्षण किया है और सत्यापित स्थिर कोड चला जाता है।
  • रखरखाव शाखा: यह वह जगह है जहां स्थिर में बग फिक्सिंग किया जाता है। जब चीजों को काम करने के लिए सत्यापित किया जाता है तो इसे स्थिर शाखा में विलय कर दिया जाता है।
  • परियोजना विशिष्ट शाखाएं: हमारे उत्पाद में प्रत्येक उप-परियोजना में एक शाखा है। साल के दौरान निर्दिष्ट समय पर सभी परियोजनाओं को इस वर्ष की रिलीज में शामिल करने के लिए "रिलीज शाखा" में विलय कर दिया गया है। यह सब विलय और सामान रिलीज से एक सप्ताह पहले नहीं किया जाता है।
  • रिलीज शाखा: यह वह जगह है जहां उप-परियोजनाओं को विलय करने के बाद वर्तमान रिलीज का सभी गन्दा विकास हो रहा है। रिलीज के बाद स्थिर के साथ विलय किया जाता है।
+0

धन्यवाद। दिलचस्प प्रणाली यदि आप सवाल पर ध्यान नहीं देते हैं तो आप कितने डेवलपर हैं ...? –

+0

उत्पाद विशेषज्ञों और डोमेन विशेषज्ञों सहित लगभग 80 दुनिया भर में। लगभग आधे डेवलपर्स हैं। – Nailer

+0

उत्कृष्ट, आपकी प्रतिक्रिया के लिए धन्यवाद। अगर केवल एसओ को मुझे यह बताने का एक तरीका था कि आपने जवाब दिया था ... –

2

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

प्रत्येक रिलीज के लिए शाखा होने का मतलब है कि आपके पास वर्तमान में उत्पादन के लिए एक शाखा है (या विलय के बाद रिलीज लंबित होने पर वास्तविक वास्तविक तैनाती से पहले रिलीज़ होने के बारे में क्या है)।

वही है जो हम वैसे भी करते हैं।

6

परिदृश्य धागा सलामी बल्लेबाज के द्वारा समझाया सुविधा शाखाओं पैटर्न का एक उदाहरण है: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

आप मुख्य विकास लाइन (ट्रंक) स्थिर रखने के लिए है और आप के बहुत सारे विकसित करने के लिए है, जब वे बहुत usefule हैं विशेषताएं जो मुख्य रूप से मुख्य रेखा को तोड़ सकती हैं।

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

+0

धन्यवाद डेविड, आप जिस पर संदेह करते हैं उस पर हिट करने वाले पहले व्यक्ति हैं। विलय (एसवीएन के साथ और शायद बाकी सब कुछ के साथ) सुखद और आसान नहीं है। –

+0

कभी-कभी विलय करना सिरदर्द होता है, लेकिन कभी-कभी यह नहीं होता है: यह परिवर्तनों के आकार पर निर्भर करता है और परिवर्तन के द्वारा कोड के किन हिस्सों पर असर पड़ता है। आम तौर पर सबवर्जन स्वचालित रूप से और सही तरीके से परिवर्तनों को रोक सकता है, लेकिन यह हमेशा इतना आसान नहीं होता है। –

+0

मैं इस जवाब में ट्रंक में कभी विकसित नहीं होने के लिए जोड़ूंगा। यह आश्वासन देता है कि ट्रंक हमेशा स्थिर रहता है। – fglez

0

जब अनुमानित घंटे 8 से अधिक होते हैं, तो शाखा का उपयोग करें।

+0

क्यों 8? हालांकि मुझे मात्रात्मक नियम पसंद हैं। –

+1

8 वास्तव में ONE_WORKING_DAY है? शायद हमें वैश्विक स्थिर बनाना चाहिए? –

1

गिट के साथ, मैं प्रत्येक छोटे बदलाव के लिए एक शाखा बना देता हूं, और मुझे यह पसंद है!

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