आप प्रत्येक स्प्रिंट को कई शाखाओं / डेवलपर्स से एकीकृत कोड कैसे संभालते हैं?

Question

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

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

हम इस बोझ को कैसे कम कर सकते हैं और हमारे कोड को एक साथ मर्ज करना आसान बना सकते हैं? मेरे दृष्टिकोण से, पीओ या एसएम ने कहानियों को अधिक कुशल तरीके से प्राथमिकता दी है, इसलिए हमारे पास इस तरह की निर्भरताएं नहीं हैं क्योंकि एक ही स्प्रिंट में कुछ समस्याएं हल हो सकती हैं। हर कोई इससे कैसे निपटता है? या यह प्रक्रिया का सिर्फ एक हिस्सा है?

Comments

क्या आपके पास एक विकास शाखा नहीं है जहाँ निरंतर एकीकरण किया जाता है?

— कायमन

मैं यहां कायमैन के साथ हूं, इसके लिए सबसे अच्छा अभ्यास निरंतर एकीकरण को लागू करना है।

— रैंडमयूएस

हैप्पी मर्ज डे! किसी भी समय आपकी समस्या द डेली डब्ल्यूटीएफ पर कुछ समान है, आप जानते हैं कि आप मुश्किल में हैं।

— user3067860

जल्दी मर्ज करें, अक्सर मर्ज करें: {सबसे छोटा टेस्ट कोड लिखें जो फेल हो जाए (लाल), सबसे छोटा प्रोडक्शन कोड लिखें जो पास (हरा), रिफलेक्टर, रेटेस्ट, मर्ज} होगा, जबकि खत्म नहीं होगा।

— ctrl-alt-delor

पहले चेक-इन जीत! कभी अंतिम मत बनो! :-)

— चॉकलेटी

Answer 1

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

जब डेवलपर अपने काम के साथ किया जाता है, तो वे एक पुल अनुरोध बनाते हैं । जब अनुमोदित किया जाता है, तो वह developशाखा में विलीन हो जाती है ।

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

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

Comments

महत्वपूर्ण हिस्सा (जो केवल आपके उत्तर में निहित है) यह है कि शाखाओं को जल्द से जल्द विलय कर दिया जाना चाहिए, आमतौर पर केवल 1 - 5 के साथ होता है, और न केवल स्प्रिंट के अंत में। एक शाखा प्रति सुविधा / कहानी, प्रति डेवलपर एक शाखा नहीं। इसके लिए जरूरी है कि कहानियां सही मायने में छोटी हों, यानी ज्यादातर दो दिन।

— आमोन

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

— बेरिन लोरिट्श

अपनी शाखा पर अलग-थलग न रहें। इस तरह मर्ज नरक शुरू होता है। मेनलाइन डेवलपमेंट का उपयोग करें, टॉगल या अन्य रन-टाइम कॉन्फ़िगरेशन के पीछे कार्य-प्रगति को अलग करें।

— रोब क्रॉफर्ड

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

— reffu

"फ़ीचर टॉगल या अन्य रन-टाइम कॉन्फ़िगरेशन के पीछे अलग-अलग कार्य-प्रगति है" आपने इसके बजाय कॉन्फ़िगरेशन में जाने से मर्ज नरक से बचा है। "मर्ज नरक" एक समय में केवल एक डेवलपर के लिए एक समस्या है और आसानी से नियमित रूप से सिंक करने से आसानी से बचा जाता है, भविष्य में सभी भविष्य के डेवलपर्स के लिए अल्पकालिक कॉन्फ़िगरेशन का टन नरक है।

— घन

Answer 2

मैंने एक ऐसी टीम में काम किया, जहां हम उसी समस्या से जूझते रहे। हमने पाया कि एकीकृत करने से पहले हमारे पास जितना कम समय था, उतना ही कम मुश्किल होता गया। मुझे पता है कि लगातार एकीकरण सिखाने वाले अधिकांश लोग हर कुछ मिनटों में बात करते हैं - हम वास्तव में हर घंटे या तो प्रतिबद्ध हैं।

हमने यह भी पाया कि सिर्फ इमारत ही काफी नहीं थी। हमें यह सुनिश्चित करने के लिए एक अच्छे परीक्षण कवरेज स्तर की आवश्यकता थी कि हम गलती से एक-दूसरे के कोड को न तोड़ दें।

Comments

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

— आमोन

हां - यह "निरंतर एकीकरण" का मतलब है! आप अन्य डेवलपर्स के परिवर्तनों के साथ अपने परिवर्तनों को निरंतर एकीकृत कर रहे हैं!

— रोब क्रॉफर्ड

@ रोब, सहमत। मेरे कथन का अभिप्राय यह नहीं था कि निरंतर एकीकरण, ठीक नहीं है, निरंतर है। बस इतना कि हमने आदर्श नहीं बनाया और अभी भी इसके करीब पहुंचने में बहुत लाभ देखा।

— डैनियल

Answer 3

• अपनी शाखाओं को अल्पकालिक रखें (ऐसा लगता है कि आप पहले से ही ऐसा कर रहे हैं)।
• अपने परीक्षा परिणाम खुद के लिए बोलने दें।
• स्प्रिंट के अंत की प्रतीक्षा न करें।

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

फिर, एक बार आपका मर्ज पूरा हो जाने के बाद, आप स्वचालन परीक्षण रिपोर्ट को एक साथ देख सकते हैं और सत्यापित कर सकते हैं कि सब कुछ सफलतापूर्वक एकीकृत किया गया है।

मैं उन अन्य उत्तरों में से एक से सहमत हूं जहां लेखक ने कहा था कि पीआरएस पीआरएस इस समस्या को हल करेगा प्रत्येक डेवलपर को अपने स्वयं के काम को मर्ज करने के लिए।

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

Answer 4

नहीं

आपकी भाषा और आप किन फ़ाइलों का संपादन कर रहे हैं, उसके आधार पर, प्रत्येक डेवलपर के लिए उन्हें अपनी शाखा पर संपादित करने का कोई मतलब नहीं हो सकता है। उदाहरण के लिए, C # में मैंने एक समय में किसी भी UI डिज़ाइनर फ़ाइलों को संपादित करने के लिए केवल एक ही व्यक्ति को सर्वश्रेष्ठ पाया है। ये ऑटोजेनरेटेड फ़ाइलें हैं, और इसलिए कोड को कभी-कभी बिना किसी स्पष्ट कारण के चारों ओर ले जाया जाता है - और यह अधिकांश विलय उपकरणों पर कहर ढाता है।

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

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

Comments

ईमानदारी से, उपयोग में संस्करण नियंत्रण उपकरण सफल शाखा और विलय के लिए अधिक महत्वपूर्ण है। यहां तक ​​कि C # कोड और संभवतः WinForms या WebForms कोड के साथ भी, जो कि आमतौर पर आपके साथ काम कर रहे हैं, वह इतना नहीं बदलते हैं । यदि वे हैं, तो शायद आपको कोड के साथ खेलने से पहले कुछ मॉकअप करने की आवश्यकता है। एक्सएएमएल आधारित यूआई केवल नियमित कोड के रूप में स्थिर होते हैं और मध्यवर्ती कोड की जाँच नहीं की जाती है।

— बेरिन लोरिट्श

@BerinLoritsch WinForms डिजाइनर कोड वास्तव में बहुत कुछ बदल सकता है, यहां तक ​​कि छोटे दृश्य परिवर्तनों के साथ भी। मैंने पाया है कि कोड की पंक्तियाँ स्वयं समान हैं, लेकिन ऑर्डरिंग बहुत अलग है - खासकर जब कई डेवलपर्स एक ही समय में संपादन कर रहे हैं। हो सकता है कि यह वीसीएस टूल का मुद्दा है (हमने कई का उपयोग किया है, हो सकता है कि हम सिर्फ गलत का उपयोग कर रहे हैं), लेकिन हमारे लिए यह बहुत आसान है कि हम अपनी प्रक्रिया को थोड़ा बदल दें।

— mmathis

@BerinLoritsch मुझे कम से कम जीत के फॉर्म (कभी इस्तेमाल नहीं किए गए वेब फॉर्म) के लिए यहां दूसरी एमएमथिस करनी होगी। Winforms UI डिज़ाइनर को फॉर्म में कहीं पर एक तुच्छ परिवर्तन के जवाब में डिज़ाइनर फ़ाइल के सभी कोड को बेतरतीब ढंग से फिर से व्यवस्थित करना पसंद है। जब तक कि आप मैन्युअल रूप से प्रत्येक कमिट (कुछ ऐसा जो किसी जटिल रूप से 10 या 15 मिनट में आसानी से हो सकता है) से पहले रीऑर्डर कर देते हैं, तो डिजाइनर फाइल का इतिहास बिल्कुल बेकार है, और अगर 2 लोग एक साथ फॉर्म के यूआई पर काम कर रहे हैं, तो इसके परिणामस्वरूप होगा नरक से एक मर्ज संघर्ष। लॉकिंग आम तौर पर एक भयानक विकल्प है, लेकिन वाइनफॉर्म के साथ वास्तव में कम से कम बुराई है।

— डैन नीली

@DanNeely, यह सिर्फ एक कारण है कि हमारी टीम WinForms कोड से दूर चली गई। एक और कारण यह है कि डिजाइनर बहुत नाजुक है, और हमारे कुछ जटिल रूपों को वैसे भी नेत्रहीन संपादित नहीं किया जा सकता है। हमने कोडबाइंड में सीधे बदलाव करने का काम समाप्त कर दिया - शायद इसलिए मुझे वहां बहुत उथल-पुथल याद नहीं है। वह और उच्च घनत्व प्रदर्शित करने वाले हमारे उपयोगकर्ता वास्तव में हमें WPF में धकेल देते हैं। एक उच्च सीखने की अवस्था के साथ एक दर्दनाक प्रक्रिया, लेकिन इसके अंत में एक अच्छा इनाम। बैकलॉग में अधिकांश कहानियाँ वैसे भी ऐप के विभिन्न हिस्सों के लिए थीं।

— बेरिन लोरिट्श

यहाँ @BerinLoritsch। जीत के रूपों ने मेरी पिछली नौकरी में एक दशक के लिए मेरे बिलों का एक बड़ा हिस्सा भुगतान किया, लेकिन मैं भविष्य में इसे फिर कभी नहीं छूने के लिए काफी खुश हूं।

— डैन नीली

Answer 5

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

यह आपको किसी masterभी चीज को तोड़ने के बिना अपने परिवर्तनों को या तो या आपकी संयुक्त विकास शाखा में वापस विलय करने की अनुमति देता है । अन्य डेवलपर तब इन परिवर्तनों को वापस अपनी सुविधा शाखाओं में विलय कर सकते हैं (या तदनुसार अपनी शाखाओं को फिर से शुरू कर सकते हैं)।

जैसा कि अन्य उत्तर पहले ही बता चुके हैं कि इसे निरंतर एकीकरण समाधान के साथ जोड़ा जाना चाहिए।

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

Answer 6

हम प्रत्येक सुविधा के लिए अलग-अलग विकास शाखा के एक दृष्टिकोण का अनुसरण कर रहे हैं, और फिर हम एकीकरण परीक्षण वातावरण में परीक्षण के लिए शाखाओं को एक क्यूए शाखा में विलय कर रहे हैं।

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

यदि सब ठीक हो जाता है, तो हम रिलीज शाखा को वापस मास्टर शाखा में विलय कर देते हैं।

Answer 7

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

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

हालाँकि, किसी ने भी आपके सबसे महत्वपूर्ण प्रश्नों में से एक को संबोधित नहीं किया है - क्या करना है जब आप सभी कोड के समान क्षेत्रों को छू रहे हों। यह वह जगह है जहां एक सीसा होना उपयोगी है जो कोड आधार से परिचित है और विभिन्न कार्यों की निर्भरता को पहचान सकता है। यदि वे काम के समय को ऑर्केस्ट्रेट नहीं करते हैं और कमिट करते हैं, तो संभवतः आप मर्ज संघर्ष और लाइन रिज़ॉल्यूशन के साथ समाप्त हो जाएंगे। बड़ी टीम के साथ टास्क का आयोजन अधिक कठिन होता है, लेकिन एक छोटी टीम के साथ इन परस्पर विरोधी कार्यों को पहचानना संभव है। लीड तब ​​भी सभी संबंधित कार्यों को एक ही इंजीनियर के पास स्थानांतरित कर सकता था, ताकि संघर्ष से पूरी तरह से बचा जा सके।