अजीब कंपनी रिलीज चक्र: जाओ वितरित स्रोत नियंत्रण?


13

इस लंबे पोस्ट के बारे में क्षमा करें, लेकिन मुझे लगता है कि यह इसके लायक है।

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

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

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

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

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

इस आवश्यकता के साथ "निरंतर एकीकरण" दृष्टिकोण जैसा कि मैं देखता हूं कि यह टूट जाता है। निरंतर एकीकरण के साथ एक नई सुविधा प्राप्त करने के लिए इसे देव-परीक्षण-ठेस के माध्यम से धकेलना होगा और यह देव में किसी भी अधूरे काम को पकड़ लेगा।

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

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

इस पर लोगों के क्या विचार हैं?

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


जवाबों:


5

क्या एक DVCS परिभाषित करता है?

वितरित DVCS में साधन भंडार के हर क्लोन जानकारी के सभी है, प्रतिबद्ध करने के लिए, अद्यतन, शाखा, मर्ज या कभी बिना छुए कि भंडार में किसी भी संशोधन के लिए खोज के लिए आवश्यक एक सर्वर । केवल एक चीज जिसे आप ऑफ़लाइन कर सकते हैं, svnवह वास्तव में फाइलों को संपादित करती है - आपको लगभग सभी svnकमांड के लिए सर्वर एक्सेस की आवश्यकता होती है , जिसमें grepping के रूप में सरल रूप में कुछ करना शामिल है svn log, इसलिए यह वास्तव में 0% से 90% के करीब है!

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

ब्रांचिंग मॉडल क्या उपयुक्त है?

मैं उस स्थिति में आ गया हूं जब आप अभी हैं। इस तरह की प्रणाली एक वास्तविक दर्द हो सकती है लेकिन आपको उन व्यावहारिक कारणों को समझना होगा जो वे इस तरह से बने और महसूस करते हैं कि वे मोचन से परे नहीं हैं । कई उपकरण विकसित किए गए हैं जो इस प्रकार की जटिलता को प्रबंधित करने में मदद कर सकते हैं

सबसे पहले, आप जो भी करते हैं, लोगों को सफल गिट ब्रांचिंग मॉडल नहीं दिखाते हैं , यह सिर्फ उन्हें भ्रमित करेगा और उन्हें बंद कर देगा। इसके बजाय, अपना स्वयं का मॉडल विकसित करें जो आपके मौजूदा वर्कफ़्लो को दर्शाता है , फिर भी आपके मौजूदा वर्कफ़्लो के साथ समस्याओं को हल करता है

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

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

इन विकल्पों पर अधिक जानकारी के लिए, करने के लिए अपने जवाब देख रणनीति एक मॉड्यूलर प्रणाली पर संस्करण नियंत्रण का उपयोग करने के , कैसे उपयोग सबवर्सन भंडार के अंदर Git भंडार के लिए? और कई कंपनियों द्वारा उपयोग किए जाने वाले एप्लिकेशन के लिए स्रोत / संस्करण नियंत्रण

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

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


1
+1 सफल
जिट

1
"अपने जीवन को आसान बनाने" के लिए +1। यह प्रमुख प्रेरक है।

5

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

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

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

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

आपको यह सुनिश्चित करने के साथ संयोजित करने की आवश्यकता है कि आपके परिनियोजन पैकेज आपके पास सर्वर बनाने के लिए आते हैं और यह परिनियोजन जहाँ तक संभव हो स्वचालित है (आपको न्यूनतम प्रयास और न्यूनतम तनाव के साथ लाइव सर्वर पर तैनात कोड को बिल्ड सर्वर विरूपण साक्ष्य से जाने में सक्षम होना चाहिए)।

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

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


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

@ मेरलेन - मुझे पता है कि लोगों को यह समझाना मुश्किल हो रहा है, लेकिन जब से मैंने एक टीडीडी तरीके से विकसित करना शुरू किया है , मैं तेजी से आश्वस्त हूं कि मेरे पास परीक्षण लिखने का समय नहीं है
मार्क बूथ

1

दूसरा सवाल आसान और छोटा है, इसलिए मैं इसे शुरू करने की कोशिश करूंगा

डीवीसीएस प्रणाली है, जहां कोई भी "आधिकारिक" कोड का स्रोत ("समझौते पर", जब उपयोग किया जाता है) को छोड़कर और अतिरिक्त स्तरों (डेटा, गैर-विहित परिभाषा) के बिना डेटा का पी 2 पी-विनिमय संभव है।

विषय पर पहला सवाल

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

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


1

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

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

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

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

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

मैं व्यक्तिगत रूप से gitसर्वश्रेष्ठ की सिफारिश करूंगा । शुरू में सीखना थोड़ा कठिन है, क्योंकि यह अधिक व्यवस्थित रूप से बढ़ता है, लेकिन अंत में यह सबसे अधिक लचीला लगता है। लेकिन तीन वितरित प्रणालियों में से कोई भी, git, मर्क्यूरियल और बाज़ार आपको अच्छी तरह से परोसेंगे (और आप अक्सर उन्हें मिक्स भी कर सकते हैं, जैसे कि mercurial git रिपॉजिटरी से / को धक्का दे सकता है और मुझे विश्वास है कि ऐसा कर सकते हैं)।

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


1

दुर्भाग्य से, कोड में बग का कोई ज्ञात समाधान नहीं है :)

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

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

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

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

DVCS:

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.