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

cookiecutter 06/18/2018. 7 answers, 6.712 views
agile scrum branching stories

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

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

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

7 Answers


Berin Loritsch 06/18/2018.

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

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

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

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


Daniel 06/19/2018.

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

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


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

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

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

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

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


mmathis 06/18/2018.

Don't

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

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

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


Florian Brucker 06/19/2018.

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

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

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

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


emarshah 06/19/2018.

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

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

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


Mars 06/19/2018.

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

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

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

Related questions

Hot questions

Language

Popular Tags