DVCS पर गलत शाखा में आने वाले डेवलपर्स को रोकना

Question

समस्या

मैं एक सॉफ्टवेयर प्रोजेक्ट पर हूं जिसमें लगभग 10 डेवलपर्स हैं, हम Mercurial के माध्यम से स्रोत कोड साझा करते हैं। हमारे पास प्रति रिलीज एक विकास और उत्पादन शाखा है। परियोजना के दौरान बार-बार हमारे पास एक शाखा से स्रोत कोड होता है यानी v1 सॉफ्टवेयर और 2 के पहले रिलीज के लिए पैच और रखरखाव शाखाओं में हो रहा है।

इसका परिणाम या तो गलत कमिट, या गलत (संभवतः गैर-QAd) कोड तक पहुँचने और गलत शाखा में तैनात होने पर खर्च होता है, अगर हम यह नहीं देखते कि कोड गलत शाखा में चला गया है।

हमारी शाखा और मर्ज डिज़ाइन / विधि

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

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

क्या होता है कि एक डेवलपर v2-dev शाखा के लिए v1-dev या v1-prod में काम के कारण काम करता है, या इससे भी बदतर, वे v2-dev को v1-prod (या इसी तरह की गलतियों) में विलय कर देते हैं।

हम ज्यादातर डेवलपर्स को -प्रोड ब्रांच तक नहीं पहुंचने के बारे में बताते हैं, हालांकि कोड अभी भी बोलते हैं। अधिक वरिष्ठ डेवलपर्स का एक समूह -प्रोड ब्रांच की देखरेख करता है।

यह ध्यान दिया जाना चाहिए कि जबकि v2 ने अभी विकास शुरू किया है, अभी भी कुछ काफी भारी पैच हो सकते हैं जो मुद्दों को ठीक करने के लिए v1 में जा रहे हैं। Ie v1 केवल अजीब छोटे पैच नहीं हो सकता है।

हमने अब तक क्या प्रयास किया है

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

डेवलपर्स द्वारा गलत शाखा के लिए संभावित कारण

• बहुत जटिल एक शाखा डिजाइन
• समानांतर में कई शाखाओं में सक्रिय विकास। (यह परियोजना हिमस्खलन-मॉडल के उपयोग के लक्षणों को प्रदर्शित करती है ।)
• डेवलपर्स DVCS को अच्छी तरह से समझ नहीं पाते हैं

प्रश्न मैंने पढ़ा है जो कुछ हद तक प्रासंगिक थे

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

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

सवाल

सॉफ्टवेयर, प्रोजेक्ट मैनेजमेंट या गवर्नेंस के रूप में क्या तरीके, जिनका उपयोग हम कम (आदर्श रूप से बंद) करने के लिए करते हैं, वे गलत तरीके से अपना समय ले रहे हैं या हमारे तैनात कोड को गंदा कर रहे हैं?

मेरे द्वारा बताए गए कारणों पर विशिष्ट टिप्पणी की जा सकती है क्योंकि ऊपर उल्लिखित की सराहना की जाएगी, लेकिन इससे आपका उत्तर सीमित नहीं होना चाहिए।

Comments

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

— शॉन मैकसमर्थी

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

— माइकल शॉ

Answer 1

समस्या यह है कि आप बदल रहे हैं एक शाखा का अर्थ प्रक्रिया के माध्यम से क्या है।

प्रारंभ में, v1 devशाखा विकास के लिए है। सभी नई सुविधाएँ वहाँ जाती हैं। भविष्य में किसी बिंदु पर, यह शाखा के लिए एक रखरखाव शाखा बन जाती है v1 release। यह समस्या की जड़ है।

यह नहीं है कि डेवलपर्स मैला हैं, इसकी अनुमति है कि शाखा की अनुमति और भूमिकाएं मैला हैं और परिवर्तन के अधीन हैं।

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

उदाहरण के लिए:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

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

एक लेख जिसे आपको पढ़ना चाहिए (और शायद 'चाहिए' के ​​लिए एक समझ) स्टीफन वेंस द्वारा उन्नत एससीएम ब्रांचिंग रणनीतियाँ हैं ।

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

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

ये भूमिकाएँ हैं:

1. मेनलाइन। यह वह जगह है जहाँ से शाखाएँ बनाई जाती हैं। हमेशा मेनलाइन से ब्रांचिंग करने से मर्ज आसान हो जाता है क्योंकि दोनों ब्रांच में एक कॉमन आंसर होगा जो ब्रांच पर ब्रांच पर नहीं होता है।
2. विकास। यह वह जगह है जहां डेवलपर्स कोड में जांच करते हैं। नियमित और सांसारिक से उच्च जोखिम परिवर्तनों को अलग करने के लिए एक से अधिक विकास शाखाएं हो सकती हैं।
3. रखरखाव। मौजूदा उत्पादन वातावरण पर बग ठीक करता है।
4. संचय। जब दो शाखाओं का विलय होता है, तो कोई मेनलाइन को अस्थिर करने का जोखिम नहीं उठाना चाहता है। इसलिए मेनलाइन को शाखा दें, शाखाओं को संचयकर्ता में मर्ज करें और चीजें व्यवस्थित होने के बाद मेनलाइन में वापस मर्ज करें।
5. पैकेजिंग। पैकेजिंग रिलीज पैकेजिंग शाखाओं में होती है। यह अक्सर रिलीज हो जाता है और रिलीज के प्रयास को विकास से अलग करने का काम करता है। देखें कि लंबे समय से जारी रिलीज को तोड़ने वाले अवांछित कमिट से कैसे निपटें? एक उदाहरण के लिए जहां पैकेजिंग विकास के साथ संघर्ष करती है।

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

ठीक है, आप कहते हैं, यह बहुत अच्छा है, लेकिन यह एक केंद्रीयकृत वीसीएस के लिए लागू किया गया था - मैं डीवीसीएस का उपयोग कर रहा हूं।

चलो git-flow मॉडल को देखें और देखें कि यह कैसे लागू होता है।

मास्टर शाखा (नीला) टैगिंग के लिए रिलीज़ शाखा है। यह मेनलाइन नहीं है। मेनलाइन वास्तव में विकसित शाखा (पीला) है। रिलीज़ शाखाएँ (ग्रीन) पैकेजिंग भूमिका हैं। कम जोखिम का विकास मेनलाइन में होता है, उच्च जोखिम का विकास फीचर शाखाओं (गुलाबी) में होता है। इस मॉडल में, विकसित शाखा में संचय किया जाता है। रखरखाव को 'हॉट फ़िक्स' माना जाता है जो लाल रंग का होता है।

जबकि भूमिका नीतियाँ सटीक मिलान नहीं हैं (प्रत्येक उत्पाद का अपना अलग जीवन चक्र है), वे एक मैच हैं।

ऐसा करना आपकी ब्रांचिंग नीति को सरल बनाना चाहिए और इसमें शामिल सभी लोगों के लिए इसे आसान बनाना चाहिए।

Comments

+1 महान तकनीकी उत्तर, यदि वह इसे प्रलेखित नहीं करता है तो काम कर सकता है, शायद नहीं। समस्या को पूरी तरह से हल करने की संभावना नहीं है जब तक कि स्पष्ट प्रक्रियाओं के साथ ब्रांचिंग स्ट्रैटेगी को दस्तावेज नहीं किया जाता है।

— मटनज़

@mattnz अधिक उन्नत शाखाएं हैं (ghads, मैं शब्द का उपयोग करने जा रहा हूं) पैटर्न। हालांकि, 'हर कोई हमेशा देव के लिए प्रतिबद्ध है' और 'तैयार होने पर, देव से एक शाखा जारी करें' आपको समाधान का 90% तरीका प्राप्त करना चाहिए। फिर केवल विषम मामले 'पैच पर काम कर रहे हैं' और फिर इसका "मुझे पता है कि मैं एक पुरानी रिलीज पर ऐसा कर रहा हूं, उस शाखा पर स्विच करें"।

मैंने इस उत्तर को स्वीकार कर लिया है क्योंकि यह हमारे SCM में किए जा रहे परिवर्तनों का आधार बनेगा। उन्नत एससीएम ब्रांचिंग स्ट्रैटिजी और गिट-फ्लो मॉडल के लिंक को विशेष रूप से सराहा गया है। हम अपने डेवलपर्स को यह समझने की कोशिश करने के लिए प्रशिक्षण में भी निवेश करेंगे कि वे HG के साथ क्या करते हैं।

— imp25

@ imp25 आपको gg के बजाय hg की ओर उपयोगी hg-flow मिल सकता है ।

@ imp25 (और hgflow के बारे में कुछ StackOverflow सवाल और जवाब - stackoverflow.com/questions/14011921/… stackoverflow.com/questions/13021807/… )

Answer 2

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

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

और एक सामान्य नियम के रूप में, ओप्पम के रेजर को लागू करें: संपूर्ण रेपो संरचना को जितना संभव हो उतना सरल होना चाहिए कि वह काम करे।

शॉन की टिप्पणी भी देखें।

Answer 3

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

मेरा सुझाव है कि आपको इस तथ्य से समस्या है कि हर कोई इन सभी शाखाओं में नियमित रूप से काम कर रहा है।

@ @ 256 ठेस के लिए एक अलग रिपॉजिटरी का सुझाव निश्चित रूप से मदद करेगा, लेकिन आपको काम को अलग तरीके से पार्सल करने पर विचार करने की आवश्यकता हो सकती है, या शायद चीजों की व्यवस्था करना ताकि कोई भी देव एक दिए गए सप्ताह में एक से अधिक शाखा पर काम नहीं कर रहा हो।

Answer 4

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

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

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

एक एकल रिपॉजिटरी पर जहां सभी डेवलपर्स एक प्रोजेक्ट पर काम कर रहे हैं, जिसमें एक सिंगल थ्रेड है, गिट फ्लो समस्या को हल करता है, लेकिन कई कंपनियों के लिए जीवन इतना सरल नहीं है।

जटिल वातावरण वह है जहां आपके पास कुल समाधान के विभिन्न पहलुओं के लिए जिम्मेदार कई टीमें हैं, जो अन्य टीमों को आंतरिक रिलीज प्रदान करती हैं। git-flow इस तरह के मुद्दे को हल करने में सक्षम नहीं है।

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

प्रभावी रूप से डेवलपर्स की एक टीम उन परिवर्तनों के समूहों को परिभाषित करती है जिन्हें स्थानांतरित करने की आवश्यकता होती है, और परिवर्तन प्राप्त करने वाले डेवलपर्स को परिवर्तनों का समूह प्राप्त होने पर परिभाषित करते हैं।

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