क्या कुछ गलत है कि हम संस्करण नियंत्रण कैसे कर रहे हैं?

Question

मैं व्यापार विश्लेषक के रूप में प्रोग्रामरों की एक टीम के साथ काम करता हूं। हमने अभी अपने उत्पाद का संस्करण २.० जारी किया है और अगले संस्करण पर ३ महीने में रिलीज़ होने के लिए काम कर रहे हैं (यह एक आंतरिक सॉफ्टवेयर उत्पाद है)। दुर्भाग्य से संस्करण 2.0 में कुछ समस्याएं हैं जिन्हें उन्हें ठीक करना पड़ा है और हम उन सुधारों को कुछ हफ़्ते में तैनात करने जा रहे हैं। समस्या यह है कि हम उन परिवर्तनों को भी लागू नहीं करना चाहते हैं जो अभी भी काम कर रहे हैं और अन्य 3 महीनों के लिए जारी किए जाने के लिए स्लेट नहीं किए गए हैं।

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

यह काफी जटिल लगता है - क्या इस प्रकार के परिदृश्य को संभालने का एक बेहतर तरीका है? हम टीम फाउंडेशन सर्वर और विजुअल स्टूडियो 2010 का उपयोग कर रहे हैं।

Comments

अपने प्रोग्रामर को आग लगाओ।

— बर्नार्ड

उन्हें एक-एक शाखा दें। दैनिक जाँच लागू करें।

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

— maple_shaft

SourceSafe में @Jan_V कुछ भी आसान नहीं है।

— maple_shaft

मैं TFS से परिचित नहीं हूं, लेकिन यह प्रश्न Mercurial या GiT के विज्ञापन की तरह पढ़ता है।

— जिम इन टेक्सास

Answer 1

V2.0 के पास वह होना चाहिए जो हमने 'स्थिर-राज्य शाखा' का उपयोग किया था (एक बार जारी होने के बाद हमने इसके लिए PerFS का उपयोग किया है, न कि TFS का)। V2 के लिए कोई भी सुधार इस शाखा के लिए किया गया होगा और फिर v3 विकास शाखा में वापस प्रचारित किया जाएगा, जबकि v3 सुविधाओं पर भी काम किया जा रहा था, अर्थात v2 पर दोष के परिणामस्वरूप v3 पर भी दोष उत्पन्न होगा।

लंबे समय तक डेवलपर की मशीनों पर परिवर्तन होने के बाद एक एकीकरण दुःस्वप्न की संभावना होगी।

Comments

MS के पास इस विषय पर एक श्वेत पत्र है (जो कहीं अधिक विस्तार से चीजों को शामिल करता है): vsarbranchingguide.codeplex.com/releases/view/38849

— रिचर्ड

और वे अभी भी v2.0 बिल्ड डेटाइम के आधार पर TFS में एक संस्करण शाखा बना सकते हैं।

— डेव जुएल

मैंने इस ब्लॉग पोस्ट को बहुत पास दिया है, मुझे लगता है कि यह बहुत अच्छी तरह से लिखा गया है। (संबंधित से संबंधित है, लेकिन अभी भी प्रासंगिक है) nvie.com/posts/a-successful-git-branching-model

— BZink

Answer 2

वैसे इस तरह के मुद्दों से निपटने के कई तरीके हैं , आम तौर पर 'ब्रांचिंग' टैग द्वारा कवर किया जाता है , प्रत्येक लाभ और डाउनसाइड के सेट के साथ।

लेकिन आपके डेवलपर्स द्वारा चुना गया दृष्टिकोण ... जी मैं इसे मौखिक रूप से यह सुनिश्चित करने के लिए उद्धृत करूंगा कि मैंने गलत नहीं किया ...

कोड ... डेवलपर की स्थानीय मशीनों पर तब तक रखे जाएंगे जब तक वे नहीं हो जाते ...

... ऊपर जैसा रास्ता शायद एकमात्र ऐसा है जो पूरी तरह से पूरी तरह से गलत है!

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

Comments

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

— कार्सन 63000

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

— जन्नत

Answer 3

1. आपके देव की मौलिक गलतफहमी है कि संस्करण नियंत्रण का उपयोग कैसे करें।
2. "सही" संस्करण नियंत्रण सॉफ़्टवेयर के बारे में चर्चा में न आएं। यह समस्या नहीं है।
3. हर कोड ट्विक समस्या को ठीक करने के लिए कठिन बना रहा है।
4. जब आप सही काम करने का फैसला करते हैं, तो आप चीजों को ठीक करते समय कोड परिवर्तन जारी नहीं रख सकते। आप सभी विकास को रोकते हैं और कोड को संस्करण नियंत्रण में प्राप्त करते हैं।
5. देव के चाहिए कम से कम बैठ जाओ और इस बारे में बात करने के लिए दर्द काफी महसूस किया।
6. सभी संस्करण नियंत्रण सॉफ्टवेयर बुनियादी अवधारणाओं का समर्थन करते हैं:
   • सभी कोड संस्करण नियंत्रण रिपॉजिटरी में जाते हैं।
   • सभी कोड फ़ाइलों में संस्करण संख्याएँ होती हैं। कोड में पुन: जाँच के बाद ये संख्याएँ स्वतः बढ़ जाती हैं।
   • एक TAG (और) विशेष संस्करण में सभी कोड फ़ाइलों को चिह्नित करता है। इस प्रकार हम सॉफ्टवेयर संस्करण 1 रिलीज को TAG कर सकते हैं, उदाहरण के लिए।
   • एक ब्रांच मुख्य ट्रंक से एक "मोड़ दूर" है ।
     • शाखा में किए गए किसी भी और सभी परिवर्तन ट्रंक को प्रभावित नहीं करते हैं।
     • आप वैकल्पिक रूप से हो सकता है विलय कुछ बिंदु पर मुख्य ट्रंक में वापस शाखा बदल जाता है।
     • इस प्रकार हम गड़बड़ी के डर के बिना प्रयोग कर सकते हैं "अच्छी चीजें।"
7. जैसा कि मैं कहता हूं, Y'all को संस्करण नियंत्रण "विश्वास की छलांग" प्राप्त करना चाहिए। विश्वास कीजिए कि बुनियादी नियमों का पालन करने से चीजें सीधी रहेंगी। अनुभवहीनता हमें अन्यथा सोचने देती है, मुझ पर विश्वास करो।
8. यहाँ एक अच्छा ट्यूटोरियल है। यह सामान्य और पर्याप्त है कि आपको बहुत सारे अन्य स्रोतों को परिमार्जन करने की आवश्यकता नहीं है
   • संस्करण नियंत्रण, बेहतर समझाया

संपादित करें

• अपने कार्य कंप्यूटर पर संस्करण नियंत्रण रखें।
  • आप इस समय टीम समन्वय से डब्ल्यू / आउट कर सकते हैं
  • टीम संस्करण नियंत्रण के साथ भी, मैं इसकी अत्यधिक अनुशंसा करता हूं
  • यदि आपकी टीम Git या Mercurial का उपयोग करती है तो आप एक स्वतंत्र, स्थानीय भंडार का उपयोग कर रहे हैं। इस प्रकार वितरित संस्करण नियंत्रण काम करता है।
  • आप अपनी टीम से विभिन्न वीसी सॉफ्टवेयर का उपयोग कर सकते हैं। हमारी टीम तोड़फोड़ का उपयोग करती है, मैं स्थानीय स्तर पर मर्क्यूरियल का उपयोग करता हूं। VC सॉफ़्टवेयर मेटाफ़ाइल्स (".svn", ".mg", छिपे हुए फ़ोल्डर) संघर्ष नहीं करते हैं।

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

अंत संपादित करें

Comments

Nitpick: "सभी कोड फ़ाइलों में संस्करण संख्याएँ होती हैं। ये संख्याएँ स्वतः बढ़ जाती हैं" कुछ VCS (उदा। तोड़फोड़, Git) में प्रति फ़ाइल के बजाय रेपो प्रति संस्करण IDs होते हैं, और संस्करण ID ज़रूरी नहीं कि संख्यात्मक (Git) हों। बेशक मूल बिंदु अभी भी खड़ा है।

— sleske

"प्रति फ़ाइल / प्रति रेपो (सिटोरी)" संस्करण। हां। यह वीसी सॉफ्टवेयर का एक मौलिक अंतर है। मैंने दोनों प्रकार का उपयोग किया है - "देश और पश्चिमी" (+1 इस संदर्भ में जिसे भी पता है)। मुझे "प्रति रेपो" मॉडल अधिक पसंद है।

— राडारबॉब

Answer 4

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

यह लेख आपको कुछ विचार दे सकता है। यह gitध्यान में रखकर लिखा गया है, लेकिन ऐसा कोई कारण नहीं है कि यह साथ काम न कर सके mercurial। मुझे लगता है कि आप इनमें से किसी का भी उपयोग नहीं कर रहे हैं, लेकिन यह भी एक समस्या है जिसे आपको ठीक करने पर विचार करना चाहिए।

Comments

टीएफएस का उपयोग करने में क्या गलत है?

— बर्नार्ड

जो आप पूरा करने की कोशिश कर रहे हैं, उस पर निर्भर करता है। पेशेवरों और विपक्ष एसओ पर एक आम विषय है। यह एक सभ्य शुरुआती बिंदु है। stackoverflow.com/questions/4415127/…

— jdl

वितरित संस्करण नियंत्रण प्रणाली हमेशा समझ में नहीं आता है।

— maple_shaft

-1: इंजीलवादियों के दावे के बावजूद, वितरित पुनरीक्षण नियंत्रण हर समस्या का जवाब नहीं है, और इस एक को हल नहीं करेगा।

— मटनज़

@ हां: शायद आप सही हैं, लेकिन मूल प्रश्न के संदर्भ में, मुझे नहीं लगता कि यह मायने रखता है कि स्रोत नियंत्रण के लिए टीएफएस का उपयोग किया जा रहा है या नहीं। जब तक टीएफएस ब्रांचिंग का समर्थन करता है, तब तक इसे ओपी की विकास टीम द्वारा उपयोग किया जाना चाहिए।

— बर्नार्ड

Answer 5

त्वरित उत्तर: विकास टीम के पास मुख्य ट्रंक से अलग कोड-बेस V2.0 को तैनात रखने के लिए एक अलग उत्पादन शाखा होनी चाहिए ।

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

आपके प्रोजेक्ट में प्रोडक्शन, स्टेजिंग, क्यूए और देव (कभी-कभी यूएटी) for health developmentजैसे कई वातावरण होने चाहिए । प्रोडक्शन रिलीज़ से पहले इन वातावरण को सेट किया जाना चाहिए ।

सभी में, कीड़े और संशोधन के लिए तैयार होना एक जारी किए गए आवेदन का समर्थन करने का तरीका है।

जैसा कि TFS को एक संस्करण नियंत्रण के रूप में उल्लेख किया गया था, मैंने उन लेखों की सूची भी संकलित की है जो स्वास्थ्य विकास के वातावरण को स्थापित करने में सहायक होंगे:

• एक छोटे से विकास दल के साथ टीम फाउंडेशन सर्वर को लागू करना
• TFS एकता मंच में आपका स्वागत है!
• टीएफएस गाइड के साथ टीम डेवलपमेंट
• एक विकास पर्यावरण की स्थापना

Answer 6

नहीं, क्योंकि जब आप VCS का उपयोग कर रहे हैं, तो आप संस्करण नियंत्रण नहीं कर रहे हैं।

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

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

Answer 7

मैं एक डेवलपर हूं और हमें वर्तमान संस्करण के सुधारों और संवर्द्धन के लिए और बाद में लगातार संस्करण के लिए अलग शाखा कोड और डीबी दिए गए हैं।

एक बार हमारे सुधार किए जाने के बाद उन्हें उत्पादन में मिला दिया जाता है और तैनात किया जाता है।

इसके अलावा हम एक अभ्यास का पालन करते हैं जैसे कि मेरे वर्तमान संस्करण के लिए मेरे पास 10 फ़िक्सेस हैं

जैसा लिखता हूं

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

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

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+F//Start Iteration 2, Fix No-1, Branch No-"ABC" संपूर्ण समाधान में खोज करने के लिए कमांड और प्रकार सटीक स्थानों का पता लगाने में बहुत मदद करता है, फाइलें जहां कोड को बदल दिया जाता है और ताजा कोड लेते हैं केवल उस हिस्से का उपयोग करने के लिए किया जा सकता है।