विकास शाखाएँ कब बनाई जानी चाहिए?

Question

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

वर्तमान में किसी एक समय में परियोजना पर 1 से 5 लोग काम कर रहे हैं। मुख्य हर समय स्थिर होना चाहिए क्योंकि हम चाहते हैं कि जब भी जरूरत हो, हम विकल्प जारी करें। हमारे पास स्प्रिंट निर्धारित नहीं है - कम से कम अभी तक नहीं - और हर 1-2 सप्ताह में जारी करें।

सही समय पर इस समय प्रत्येक व्यक्ति आवेदन भर में कीड़े ठीक कर रहा है। कुछ हफ़्ते में हम ऐप के लिए एक नए बड़े घटक पर विकास शुरू करेंगे।

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

क्या किसी को इस पर कुछ मार्गदर्शन है?

Comments

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

— जॉर्डन

@ जोर्डन: एक पूरी तरह से निराधार डर नहीं।

— रॉबर्ट हार्वे

Answer 1

मैं मनमानी शाखाओं यानी फ्रेड के बगफिक्स या हैरी के बगफिक्स के शौकीन नहीं हूं। मैं एक (स्वतंत्र) सुविधा के साथ बहुत अधिक सहज हूं जो एक शाखा को कई डेवलपर्स को एक सुविधा पर संचालित करने की अनुमति देता है; लेकिन इस सुविधा के विलय के बाद ही यह पूर्ण होगी।

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

निश्चित नहीं है कि TFS विलय में कितना अच्छा है, लेकिन मुझे यकीन है कि आप कुछ महीनों में जान जाएंगे :)

Comments

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

— लगाते हैं

Answer 2

हम एक एकल विकास शाखा से नहीं मिल सकते क्योंकि हम अन्य कार्य पूरा होने के दौरान मेन में विलय करना चाहते हैं।

ऐसा लगता है कि आप पहले से ही जानते हैं कि कई विकास शाखाएं बननी चाहिए। दो संभावित परिदृश्य दिमाग में आते हैं:

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

Answer 3

डीवीसीएस के साथ काम की शाखाएं

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

हम लगभग कभी भी स्पष्ट शाखा नहीं बनाते हैं, लेकिन फिर हमारे स्प्रिंट 1 सप्ताह से अधिक लंबे नहीं होते हैं और कार्ड को पूरा होने में 1-2 दिन से अधिक नहीं लगते हैं।

इसके अलावा, आप कोड के अन्य भागों या अन्य परियोजनाओं से काम में थ्रेडिंग करके मर्ज दर्द को कम कर सकते हैं ताकि लोगों को हर समय कठिन मर्ज करने की जरूरत न हो।

Answer 4

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

Answer 5

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