एक छोटी टीम के लिए एक संस्करण नियंत्रण शाखा नीति का परिचय


17

मैं एक ठेकेदार हूं जो हाल ही में एक फर्म के साथ शुरू हुआ है।

टीम 3 डेवलपर्स है जिसमें 2 जूनियर से लेकर मध्य स्तर के देवता शामिल हैं, एक ही स्तर पर दूसरे के साथ जल्द ही शुरू हो रहा है, और खुद (6 साल xx)। दोनों मौजूदा डेवलपर्स के लिए यह विश्वविद्यालय / कॉलेज से बाहर उनका पहला काम है, और उनके पास अपने काम की देखरेख करने वाले वरिष्ठ डेवलपर पहले कभी नहीं थे।

कोई स्पष्ट संस्करण नियंत्रण नीति नहीं है। डेवलपर्स ट्रंक पर सभी विकास करते हैं और फिर अपनी विकास मशीनों से सीधे उत्पादन के लिए तैनात करते हैं। मौजूदा टीम ब्रांचिंग से परिचित नहीं है।

मैं यह सब बदल रहा हूं और इस तारीफ के लिए एक संस्करण नियंत्रण नीति के साथ CI, TDD टेस्ट / स्टेजिंग / प्रोडक्शन सर्वर आदि पेश कर रहा हूं।

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

मैंने उनके लिए कुछ पॉइंटर्स लिखे हैं, लेकिन क्या मुझे टीम के अनुभव को ध्यान में रखते हुए कुछ और जोड़ना / जोड़ना, संशोधन करना चाहिए?

संस्करण नियंत्रण नीति

विकास ट्रंक पर किया जाता है

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

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

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

यदि हम एक रिलीज शाखा की रणनीति अपनाते हैं तो ट्रंक स्प्रिंट के अंत में प्रति स्प्रिंट के अनुसार एक बार रिलीज शाखा में विलीन हो जाता है।

यदि हम प्रति रिलीज की रणनीति के अनुसार अलग शाखा को अपनाते हैं, तो ट्रंक कभी भी रिलीज़ शाखा में विलय नहीं होता है

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


मेरी तीन सर्वर रखने की योजना है। टेस्ट पर्यावरण जो हमेशा नवीनतम कोड को रेपो में चला रहा है। एक स्टेजिंग वातावरण जो स्टेजिंग / टेस्टिंग रिलीज़ कैंडिडेट कोड और यूएटी उद्देश्यों और उत्पादन वातावरण के लिए नवीनतम रिलीज़ उम्मीदवार चला रहा है।

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

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


मुझे लगता है कि सुविधा शाखा एक कदम बहुत दूर है और मैं इसे हटा दूँगा।

तो अनिवार्य रूप से यह नीचे आता है) ख) कोई शाखा नहीं) बी) एक रिलीज शाखा और ट्रंक, और सी) एक रिलीज शाखा प्रति रिलीज और ट्रंक।

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


3
क्या आपने इस तरह से एक स्पष्टीकरण जोड़ने पर विचार किया? इसी तरह, यहाँ कैसे किया जाता है । इसके अलावा, आप "माइक्रोसॉफ्ट टीम फाउंडेशन सर्वर शाखाओं में बंटी गाइडेंस" (जैसे भेजा जाँच की थी यहाँ )?
गन्नत


1
ध्यान रखें कि मैं TFS का उपयोग नहीं कर रहा हूँ, जैसे कि GCS की तरह DVCS नहीं। यह थोड़ा विशिष्ट लगता है।
MrBliz

2
उस लिंक के अंत में कहा गया है: "जब आप कोड जारी करते हैं, तो हर कोई ट्रंक से दूर काम करता है। जब आप कोड जारी करते हैं तो शाखा जारी होती है। जब आपको पहले से जारी कोड के लिए बग फिक्स बनाने की आवश्यकता होती है। प्रोटोटाइप के लिए शाखा।" मेरा सुझाव है कि एक साधारण शुरुआत के लिए आप केवल टैग जारी करते हैं जब आप निश्चित रूप से सुनिश्चित होते हैं कि वे पूर्ण हो गए हैं। जब तक आपके पास कई सुविधाओं पर काम करने वाले कई डेवलपर्स नहीं होते हैं, तो 1 से अधिक शाखा होने की आवश्यकता नहीं है। हर कोई सुविधाओं को जोड़ता है, हर कोई रिलीज के उम्मीदवार को ठीक करता है, हर कोई सहमत है जब यह टैग के लिए तैयार है। इसका मतलब है कि आपको बाद में बग फिक्स के लिए केवल शाखाएं सौंपनी होंगी।
TafT

1
मैं इसे एक जवाब के रूप में डालने में असहज हूं, क्योंकि यह बहुत अधिक राय आधारित है, लेकिन मुझे "अंतिम ज्ञात अच्छे" टैग (LKG) का उपयोग करने के लिए लोगों को समझाने में बड़ी सफलता मिली है, जो ट्रंक पर एक चलता-फिरता टैग है जो अंतिम "धन्य" की पहचान करता है "संस्करण (CCB, परीक्षण, आदि)। डेवलपर्स को बताया जाता है कि इस एलकेजी टैग से रिलीज किए जाएंगे, न कि ट्रंक के प्रमुख, और इसके अलावा, वे उस समय का उपयोग करने के लिए स्वतंत्र हैं जो कुछ भी दृष्टिकोण उनके लिए समझ में आता है। मैंने इस पैटर्न को सहजता से सुविधा-शाखाएँ उत्पन्न करने के लिए पाया है जब समय सही है, बिना किसी प्रयास के या डेवलपर्स के हिस्सों पर अतिरिक्त काम किए बिना।
Cort Ammon - मोनिका

जवाबों:


16

3-4 देवों की एक टीम के लिए, आप बहुत अधिक शाखाएँ प्रस्तावित कर रहे हैं।

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

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

हर स्प्रिंट के लिए एक अलग रिलीज शाखा होना पागल है। आपको अगले के लिए कोड से पृथक एक स्प्रिंट से कोड की आवश्यकता क्यों है? क्यों न केवल एक स्थिर रिलीज शाखा है जो प्रत्येक स्प्रिंट के साथ आगे बढ़ती है?

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

लगभग कोई भी गैर-तुच्छ नई सुविधा वास्तविक समय में विकास, डेवलपर परीक्षण, दैनिक रुकावट और अन्य गतिविधियों आदि के लिए कम से कम एक सप्ताह लेने वाली है।

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

हमारे पास 1 + मिलियन लाइन कोडबेस पर काम करने वाले 4 डेवलपर्स की एक टीम है और इस तरह से हम काम करते हैं:

  • मुख्य शाखा जहां सारा विकास किया जाता है
  • प्रमुख रिलीज के प्रति एक शाखा (प्रति वर्ष लगभग एक बार किया जाता है)

एक प्रमुख नियम है: उस कोड की जांच न करें जो निर्माण नहीं करता है।

बस। सरल, समझने में आसान, हमें जो अलगाव चाहिए (किसी भी समय हम किसी भी संस्करण के लिए रिलीज़ बिल्ड बना सकते हैं)।

एक शाखा पर किए गए सभी विकास कार्य करने के लिए अपसाइड करें:

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

10
"ध्यान रखें कि एक शाखा का एकमात्र वास्तविक लाभ कोड अलगाव है। इसका मतलब है कि कोड को अलग-थलग करने के लिए आपको एक ठोस कारण की आवश्यकता है।" - कोड समीक्षा के बारे में कैसे? मुझे लगता है कि यह एक अच्छा कारण है, यहां तक ​​कि केवल दो देवों के साथ भी।
ब्लूराजा - डैनी पफ्लुगुएफ्ट

2
कोड की समीक्षा और शाखाएं वास्तव में संबंधित नहीं हैं। क्या आप कह रहे हैं कि आप समीक्षा करने से पहले किसी विशेष शाखा में कोड की जाँच नहीं करना चाहते हैं?
17 की 26

5
@ 17of26, हाँ। कोड समीक्षा आमतौर पर मेनलाइन पर होने के लिए एक शर्त के रूप में उपयोग की जाती है । इस प्रकार आपको इससे पहले किसी तरह से कोड दिखाना होगा: आपके मॉनिटर पर, ईमेल में या - कई सेटअप में - एक शाखा पर। यह GitHub या gerrit जैसे रेपो प्रबंधन टूल के साथ सबसे अच्छा काम करता है।
पॉल ड्रेपर

3
TFS अलमारियों के माध्यम से कोड समीक्षाओं का समर्थन करता है, जो स्रोत नियंत्रण में अस्थायी होल्डिंग क्षेत्र हैं। जब तक यह समीक्षा की जाती है तब तक कोड वहां रह सकता है और तब चेक इन किया जा सकता है।
17 की 26

2
मुझे लगता है कि बिंदु है, शाखाएं वास्तव में कोड समीक्षा करने के लिए उपयोग करने के लिए सही तंत्र नहीं हैं।
17 की 26

31

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

क्या उनके पास एक समस्या है जिसे हल करने की आवश्यकता है? पहले इस प्रश्न का उत्तर देना महत्वपूर्ण है, क्योंकि या तो उन्हें वास्तव में कोई समस्या है और वे आपके सुझावों का स्वागत करेंगे, या वे पूरी तरह से ठीक काम कर रहे हैं जैसा कि वे वर्तमान में करते हैं, और आप उन्हें अपने काम करने के तरीके पर जोर दे रहे हैं , सिर्फ इसलिए कि आप पसंद करते हैं इस तरह से काम करो।

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

  • एक डेवलपर को यह सोचना होगा कि परिवर्तन कहाँ होना चाहिए,

  • किसी को शाखाओं का प्रबंधन करना है और शाखाओं से ट्रंक में विलय करना है,

  • शाखाओं के बीच विलय कम से कम बार किया जाता है, जिसका अर्थ है कि किसी व्यक्ति को उन संघर्षों से निपटना पड़ता है जो दो कमिट के बीच संघर्ष की तुलना में बड़े और अधिक कठिन होते हैं,

  • हर कमिट निरंतरता में अपना रास्ता नहीं खोजता, जो डेवलपर्स को उन प्रभावों के बारे में जानकारी देता है जो एक प्रतिबद्धताओं (विशेष रूप से प्रतिगमन) के बारे में हो सकते हैं।

यह तथ्य कि:

मौजूदा टीम ब्रांचिंग से परिचित नहीं है

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


3
अच्छी तरह से इस मॉडल में, आप अस्थिर कोड को ब्रांचिंग के बिना उत्पादन पर कैसे रोक सकते हैं?
MrBliz

2
@MrBliz: स्विच के माध्यम से। आप डेवलपर्स के लिए एक सुविधा को सक्रिय कर सकते हैं, लेकिन अंत उपयोगकर्ताओं के लिए इसे निष्क्रिय कर सकते हैं यदि यह आरटीएम के लिए तैयार नहीं है।
आर्सेनी मूरज़ेंको

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

4
@MrBliz आप अस्थिर शाखाओं को रिलीज शाखाओं में अलग करके उत्पादन के लिए हो रही बंद कर देते हैं (यह बिल्कुल उनका उद्देश्य है) और इसका परीक्षण करके। फ़ीचर शाखाएँ इसमें मदद नहीं करती हैं; वास्तव में ये बड़े, गैर-एकीकृत,
कठिनता

1
@MrBliz हाँ, मैंने देखा है कि (और मुझे लगता है कि आप इसे सही के बारे में मिला, अगर केवल समर्थन करने का तर्क समझाने में चूक गए)। यह सिर्फ इतना है कि न तो आपकी टिप्पणी और न ही इस उत्तर का स्पष्ट रूप से उल्लेख है कि क्या यह रिलीज या फीचर शाखाओं (या दोनों?) के बारे में है, इसलिए मैंने अंतर पर जोर देने के लिए टिप्पणी की । FWIW इस बारे में अस्पष्ट है कि शायद मैं इस जवाब के बारे में नापसंद करता हूं
gnat

3

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

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


प्रभावी रूप से किसी भी एक समय में केवल तीन सक्रिय शाखाएँ (रिलीज़, रिलीज़ उम्मीदवार और ट्रंक) होंगी, और अधिकांश समय केवल रिलीज़ शाखा और ट्रंक।
MrBliz

पुरानी शाखाओं को TFS में हटा दिया जाएगा, या अधिक सटीक रूप से छिपाया जाएगा।
MrBliz
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.