TFS 2010 का उपयोग करने का अनुभव: (नियंत्रण प्रणाली। अधिकार और नीतियां)

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

शाखाओं में क्रियाओं पर अनुमतियाँ सेट करना

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

चित्र 1 - साइट और एकीकरण शाखा पर इंटीग्रेटर अधिकार


चित्र 2 - साइट और एकीकरण शाखा पर डेवलपर्स के अधिकार

डेवलपर्स और इंटीग्रेटर को अन्य लोगों की शाखाओं पर चढ़ने और उनमें परिवर्तन करने के लिए भी मना करना आवश्यक है, उदाहरण के लिए, मैंने इंटीग्रेटर को ट्रोलिक डेवलपर शाखा में परिवर्तन करने से मना किया, चित्र 3 देखें और उसे केवल कोड को देखने का अधिकार छोड़ दिया।
चित्र 3 - डेवलपर शाखा में इंटीग्रेटर अधिकार

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

1. आप अन्य लोगों की शाखाओं में कोड नहीं बदल सकते
2. साइट और एकीकरण शाखा में कोड को बदलने का अधिकार केवल इंटीग्रेटर को है
3. हर कोई किसी भी शाखा से कोड पढ़ सकता है

चेक-इन नीति

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

हमें 4 विकल्पों में से चुनने का अवसर दिया गया है:

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

बेशक, मैं सब कुछ चुनना चाहता हूं, क्योंकि मैं कोड की गुणवत्ता के बारे में बहुत चिंतित हूं, चित्रा 5 देखें
चित्र 5 - चेकइन नीति

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

अगला चरण - मुझे एक परीक्षण नीति जोड़ने की आवश्यकता है, यहां स्थिति थोड़ी अधिक जटिल है। अभी हमारे पास परीक्षणों की सूची नहीं है। हमें इसे बनाने की जरूरत है। सबसे पहले, MyClass.cs फ़ाइल में जोड़ें। परियोजना में हमारे पास एक सरल विधि है, जो कि सही है अगर संख्या 0 से अधिक है और अन्यथा झूठी है, तो चित्र 7 देखें।

चित्रा 7 - विधि वर्ग MyClass

उसके बाद, हम MyMethod विधि के लिए एक परीक्षण बना सकते हैं और इस परीक्षण को परीक्षणों की सूची में जोड़ सकते हैं। ऐसा करने के लिए, हमें समाधान के लिए एक परीक्षण परियोजना जोड़ने की आवश्यकता है, बस समाधान पर खड़े होकर और मेनू जोड़ें-> नई परियोजना-> परीक्षण परियोजना पर राइट-क्लिक करके ऐसा करें। इस ऑपरेशन के बाद, परीक्षण फ़ाइल दिखाई दी, और समाधान आइटम सूची में परीक्षण के लिए सेटिंग्स, लेकिन फ़ाइल में एक भी परीक्षण या परीक्षण सूची नहीं है, क्योंकि हमने अभी तक परीक्षण नहीं बनाए हैं, और अब जब परीक्षण परियोजना बनाई गई है, तो हम आसानी से सही उपयोग कर सकते हैं। माउस, विधि पर खड़ा है, चित्र 8 देखें।

चित्रा 8 - एक इकाई परीक्षण बनाना

इकाई परीक्षण स्वचालित रूप से किया गया था, और डिफ़ॉल्ट रूप से, यह विफल रहता है। इसके अलावा, अब यह यूनिट टेस्ट टेस्ट फाइल TestSolution.vsmdi-> ऑल लोडेड टेस्ट में है। हालांकि, हमें परीक्षणों की एक सूची बनाने की आवश्यकता है जो प्रत्येक चेकइन ऑपरेशन से पहले चलेगी। समाधान में फ़ाइल TestSolution.vsmdi पर क्लिक करके ऐसी सूची बनाएं। चलो इसे TestForCheckInPolitics कहते हैं और फिर हमारी इकाई परीक्षण को इस सूची में ले जाते हैं, चित्र 9 देखें।
चित्र 9 - चेकइन नीति के लिए परीक्षणों की सूची बनाना

अब जब हमारे पास परीक्षणों की एक सूची है, तो हमें इसे नियंत्रण में जोड़ने की आवश्यकता है। ऐसा करने के लिए, परीक्षण फ़ाइल (TestSolution.vsmdi) की जांच करें। उसके बाद हम इसे पॉलिसी में जोड़ सकते हैं। ऐसा करने के लिए, चित्र 5 में दिखाई गई विंडो में परीक्षण नीति का चयन करें, परीक्षण फ़ाइल और CheckIn नीति के लिए परीक्षणों की सूची निर्दिष्ट करें, चित्र 10 देखें
चित्र 10 - चेकइन नीति के लिए एक परीक्षण सूची का चयन करना

इसके अलावा, यह सुनिश्चित करने के लिए कि डेवलपर केवल असाइनमेंट पर कोड बदलता है, हम कार्य आइटम के साथ अंतिम नीति - लिंक चेकइन भी स्थापित करेंगे।
CheckIn नीति कॉन्फ़िगर होने के बाद, हम अपने कोड की जाँच करने का प्रयास करेंगे। जैसा कि चित्र 11 से देखा जा सकता है, हमें पूरी तरह से भय का सामना करना पड़ा।
चित्र 11 - चेकइन नीति ने काम किया है

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

इकाई परीक्षण को बदलें ताकि यह गुजर जाए, और हमारे काम को कार्य मद से जोड़ दें, चित्र 13 देखें।

चित्र 13 - किसी कार्य वस्तु से जोड़ना

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