TFS 2010 का उपयोग करने का अनुभव: (नियंत्रण प्रणाली। शाखाएँ। निर्माण)

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

परिचय

शुरू करने के लिए, हमारे पास 5 साल पहले क्या था: हमारे पास, और अभी भी एक उत्कृष्ट, मेरी राय में, संस्करण नियंत्रण प्रणाली आईबीएम तर्कसंगत संबंधक है, इसके अलावा एक परिवर्तन प्रबंधन और कार्य वितरण प्रणाली आईबीएम तर्कसंगत तर्कसंगत भी है। । एक निश्चित बिंदु तक, जबकि सभी विकास सी ++ में विशेष रूप से किए गए थे, यह पर्याप्त था। सच है, एक छोटी सी समस्या थी, सिस्टम Microsoft को छोड़कर सभी विकास उत्पादों में पूरी तरह से एकीकृत था। मुझे नहीं पता कि यह आईबीएम और माइक्रोसॉफ्ट के बीच एक अनस्पोक युद्ध के कारण था, लेकिन सिस्टम ने विजुअल स्टूडियो 2005 के साथ बेहद अस्थिर काम किया, अक्सर फाइलों की स्थिति को गलत तरीके से प्रदर्शित किया जाता है, विजुअल स्टूडियो लगातार तब क्रैश हो जाता है जब हम उन कार्यों को चालू कर देते हैं जिनकी हमें आवश्यकता होती है। इसके अलावा, सिस्टम तक पहुंचने के लिए एक प्रोटोकॉल का उपयोग किया गया था, इसलिए हमारी कंपनी में, केवल वे उपयोगकर्ता जो कंपनी के डोमेन में थे, सिस्टम तक पहुंच सकते थे, जो स्वचालित रूप से हमें पर्सनल लैपटॉप से ​​सिस्टम में लॉग इन करने की अनुमति नहीं देते थे। बेशक, समय के साथ, इन सभी कमियों को लगभग समाप्त कर दिया गया था, लेकिन उस समय, यह मामला था।
यह एक नई प्रणाली की खोज का कारण था, लंबी खोजों के बाद, हमने टीएफएस 2005 की कोशिश करने का फैसला किया। वास्तव में, हम कह सकते हैं, हमने काम करना सीखा, और हमारे लिए एक नई प्रणाली का अध्ययन किया। हमने इस पर लंबे समय तक काम नहीं किया, लगभग 2 साल, और तुरंत TFS2010 की कोशिश करने का फैसला किया। मैं इस प्रणाली के बारे में थोड़ी बात करना चाहता हूं, और मैं सबसे बुनियादी के साथ शुरू करूंगा, मेरी राय में, भाग - संस्करण नियंत्रण प्रणाली।

जैसा कि मैंने कहा, हमने अपनी पूरी जिंदगी UCM सेटअप के साथ ClearCase पर काम किया है और UCM प्रक्रिया के अनुसार सब कुछ करने के लिए उपयोग किया जाता है। इस प्रक्रिया में मुख्य क्रियाओं में से एक थी डिलीवर (डेवलपर से परिवर्तन स्थानांतरित करना) और रिबेस (परिवर्तन प्राप्त करना) संचालन। यह कागज पर बहुत सरल दिखता है, डेवलपर अपनी शाखा में बदलाव करता है, और जब वह काम पूरा कर लेता है, (टीएफएस के संदर्भ में मर्ज करता है) उन्हें एकीकरण शाखा में डाल देता है, तदनुसार, यदि डेवलपर परिवर्तन प्राप्त करना चाहता है, तो उसे फिर से जमा करना होगा (फिर से, मर्ज में करें) डेवलपर शाखा), चित्र 1 देखें।


चित्र 1 - डिलीवरी और रिबेस ऑपरेशन

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

चित्रा 2 - ClearCase में ऑपरेशन ट्री

और इसलिए, हमें एक उपकरण की आवश्यकता थी जो हमें ठीक उसी प्रक्रिया का पालन करके काम करने की अनुमति दे। आइए TFS2010 के साथ ऐसा ही करने की कोशिश करते हैं।

शाखाएँ बनाएँ

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

चित्र 3 - परीक्षण परियोजना से जुड़ना

अब, टीम एक्सप्लोरर में परियोजना के स्रोत नियंत्रण पर क्लिक करके स्रोत नियंत्रण एक्सप्लोरर खोलें, चित्र 4 देखें और परियोजना के लिए प्रोजेक्ट-एकीकरण फ़ोल्डर जोड़ें, यह फ़ोल्डर रिलीज़ कोड को स्टोर करने के लिए हमारे लिए आधार होगा, वास्तव में, यह एकीकरण शाखा होगी, इसके निर्माण के बाद और संस्करण नियंत्रण पर जोड़ें, तुरंत इसे एक शाखा में बदलें, चित्र 5 और चित्रा 6 देखें।

चित्रा 4 - कॉलिंग सोर्स कंट्रोल एक्सप्लोरर


चित्रा 5 - एक एकीकरण शाखा बनाना


चित्रा 6 - एक एकीकरण शाखा बनाना

अब आपको एक साइट शाखा बनाने की आवश्यकता है, जो वह जगह होगी जिसके माध्यम से डेवलपर्स कोड का आदान-प्रदान करेंगे। इस शाखा को हमारी बनाई गई एकीकरण शाखा से शाखा चाहिए, चित्र 7 देखें, और हम इससे एक शाखा बनाएंगे, चित्र 8।

चित्र 7 - पेड़ की शाखाएँ


चित्र 8 - साइट शाखा बनाना

और अंत में, हमें उसी एल्गोरिदम का उपयोग करके डेवलपर की शाखा बनाने की आवश्यकता है, हम केवल साइट शाखा से शाखा करेंगे। हम दो डेवलपर्स के लिए दो शाखाएँ बनाएंगे, चित्र 9 देखें।

चित्र 9 - डेवलपर की शाखा

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

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

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

उपयोगी लिंक:
टीम डेवलपमेंट विजुअल स्टूडियो टीम फाउंडेशन सर्वर का उपयोग करते हुए: संदर्भ