... या TFS 2010 में कुछ कार्यों को कैसे स्वचालित किया जाए।

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

विचार

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

जब संबंधित तत्वों में राज्य के परिवर्तन से समय की बचत होगी तो आप बहुत सारे परिदृश्यों के साथ आ सकते हैं। मानक योजना में, जब कोई स्थिति बदलती है, तो समान कार्य आइटम से संबंधित फ़ील्ड को बदलना संभव है, लेकिन यह पर्याप्त नहीं है।

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

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



यह भी उपयोगी कार्यक्षमता होगी जब सभी कार्यों को हल किया जाता है, तो इतिहास की स्थिति स्वचालित रूप से हल की स्थिति में बदल जाती है।

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

कार्यान्वयन

हां, जैसा कि आप पहले ही अनुमान लगा सकते हैं, उपरोक्त उद्देश्यों के लिए आप टीएफएस 2010 के लिए सर्वर ऐड-ऑन का उपयोग कर सकते हैं - टीएफएस एग्रीगेटर । चूंकि यह ऐड-ऑन सर्वर साइड पर काम करता है, इसलिए विभिन्न नियमों का कार्यान्वयन बहुत जल्दी होगा। बहुत पहले प्रसंस्करण, ज़ाहिर है, 7-10 सेकंड लगेंगे, क्योंकि एक कनेक्शन स्थापित और कैश किया जाएगा। अन्य अपडेट आमतौर पर आपके क्लाइंट को अपडेट करने की तुलना में तेजी से होते हैं।

स्थापना

TFS एग्रीगेटर में केवल दो फाइलें होती हैं: एक कार्य निष्पादन लाइब्रेरी और एक XML प्रारूप कॉन्फ़िगरेशन फ़ाइल।

ऐड-ऑन डाउनलोड करने और इसे अनज़िप करने के बाद, दोनों फ़ाइलों को TFS ऐड-ऑन डायरेक्टरी में ट्रांसफर करना होगा। यह आमतौर पर यहां स्थित है: C: \ Program Files \ Microsoft Team Foundation Server 2010 \ Application Tier \ Web Services \ bin \ Plugins।

वह सब है। टीएफएस निर्दिष्ट निर्देशिका की निगरानी करता है, और जब फ़ाइल की प्रतिलिपि बनाई जाती है, तो सर्वर इसे मेमोरी में लोड करेगा।

समायोजन

सभी सेटिंग्स AggregatorItems.xml फ़ाइल में निहित हैं। इस फ़ाइल में कनेक्शन के बारे में और प्रक्रिया में लागू होने वाले सभी नियमों के बारे में जानकारी होगी।

तो, AggregatorItems.xml फ़ाइल के मुख्य घटकों पर विचार करें:

  <? xml संस्करण = "1.0" एन्कोडिंग = "utf-8"?> 

फ़ाइल हेडर छूने और बदलने के लायक नहीं है।

  <AggregatorItems tfsServerUrl = "http: // tfs2010dev: 8080 / tfs"> 

AggregatorItems : विन्यास के लिए मुख्य तत्व, मूल तत्व।
tfsServerUrl: TFS सर्वर को पता।

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

  <AggregatorItems tfsServerUrl = "http: // violet-tape-tfs: 8080 / tfs / MigrationProject"> 

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

  <AggregatorItem OperationType = "Numeric" ऑपरेशन = "Sum" linkType = "जनक" linkLevel = "2" workItemType = "कार्य"> 

AggregatorItem : एक एकत्रीकरण नियम का संकेत देता है।
OperationType : निर्धारित करता है कि क्या गणितीय कार्रवाई की जाएगी या क्या यह पाठ चर के साथ काम करेगा। अब तक, केवल दो मूल्य उपलब्ध हैं: न्यूमेरिक या स्ट्रिंग। डिफ़ॉल्ट न्यूमेरिक है। यदि न्यूमेरिक प्रकार का चयन किया जाता है, तो कार्य क्षेत्र डबल या पूर्णांक प्रकार का होना चाहिए।
संचालन : इंगित करता है कि भाग लेने वाले क्षेत्रों में कौन सा गणितीय ऑपरेशन लागू किया जाएगा। वर्तमान में केवल जोड़, घटाव, गुणा, भाग (योग, घटाना, गुणा, भाग) का समर्थन किया। डिफ़ॉल्ट रूप से, इसके अलावा चयनित है।
linkType : लिंक के प्रकार को इंगित करता है कि क्या माता-पिता या एक ही तत्व एकत्रीकरण लक्ष्य होगा। तदनुसार, संभावित मूल्य हैं: स्व, माता-पिता। डिफ़ॉल्ट स्व होगा।
linkLevel : यदि linkType को पैरेंट के रूप में निर्दिष्ट किया गया है, तो यह पैरामीटर बताता है कि कितने माता-पिता ऊपर जाते हैं। डिफ़ॉल्ट रूप से, मान एक है।
workItemType : कार्य आइटम का नाम (कार्य, बग, और इसी तरह) जिस पर नियम लागू किया जाएगा।

  <TargetItem नाम = "कुल अनुमान" /> 

TargetItem : अद्यतन किए जाने वाले TFS में फ़ील्ड को इंगित करता है। एक भी प्रति नियम में हो सकती है।
नाम : TFS में फ़ील्ड का नाम जो एकत्रीकरण परिणाम के लिए अभिप्रेत है।

  <SourceItem नाम = "अनुमानित देव कार्य" /> 

SourceItem : डेटा स्रोत होगा TFS में फ़ील्ड इंगित करता है। इसे कई बार इस्तेमाल किया जा सकता है।
नाम : TFS में फ़ील्ड का नाम जहाँ से डेटा लिया जाएगा।

  <शर्तें> 

स्थितियां : उन परिस्थितियों को निर्धारित करें जो एकत्रीकरण ट्रिगर होने पर पूरी होनी चाहिए। वैकल्पिक क्षेत्र।

  <स्थिति बायीं ओर = "समाप्त तिथि" ऑपरेटर = "ग्रेटरथन" राइटवैल्यू = "$ अब $" /> 

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

  <मैपिंग> 

मैपिंग : स्ट्रिंग एकत्रीकरण के लिए मूल्यों की एक सूची प्रदान करता है।

  लक्ष्यीकरण मैपिंग करें = "पूर्ण" समावेशी = "और"> 

मैपिंग : संभव एकत्रीकरण के एकल तत्व का प्रतिनिधित्व करता है। यदि स्थिति काम करती है, तो मैपिंग का परिणाम लक्ष्यव्यू से एग्रीगेशन इटेम के लिए लक्ष्यवैल्यू में मूल्य का प्रवेश होगा।
targetValue : प्रतिस्थापन के लिए उपयोग किया जाने वाला मान।
समावेशी : यह पैरामीटर जिम्मेदार है कि क्या सभी (और) या किसी एक (या) मूल्य को मैपिंग से कार्य करने के लिए निर्धारित SourceValue से मिलना चाहिए।

  <SourceValue> निकाल दिया गया </ SourceValue> 

SourceValue : ट्रिगर करने के लिए मानचित्रण को संतुष्ट करने वाले संभावित मान।


यहां यह ध्यान दिया जाना चाहिए कि किसी कार्य आइटम से फ़ील्ड नाम का उल्लेख करते समय, संक्षिप्त नाम लिखना आवश्यक है, न कि नाम स्थान के साथ।

इस पर परिभाषाएं समाप्त हो गई हैं, और ठोस उदाहरणों पर विचार किया जा सकता है।

उदाहरण

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

  <AggregatorItem OperationType = "String" linkType = "जनक" linkLevel = "1" workItemType = "कार्य">
    <लक्ष्यित नाम = "राज्य" />
    <SourceItem नाम = "राज्य" />
    <मैपिंग>
       लक्ष्यीकरण मैपिंग करें = "WIP" समावेशी = "या">
          <SourceValue> सक्रिय </ SourceValue>
       </ मानचित्रण>
    </ मैपिंग>
 </ AggregatorItem> 

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

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

ईमानदारी से, इस विशेष परिवर्तन के साथ, मैं असाइन किए गए फ़ील्ड का मान NETWORK सेवा में रीसेट कर देता हूं, लेकिन अन्य स्वचालित बदलावों के साथ ऐसा नहीं होता है। चमत्कार! मुझे उम्मीद है कि डेवलपर्स इस समस्या में मेरी मदद करेंगे, और मैं आपको बताऊंगा कि क्या गलत था।

एक अन्य उदाहरण है, इतिहास का पुनरुत्पादित अवस्था में परिवर्तन जब सभी कार्य पूरे हो जाते हैं।

 

 <AggregatorItem OperationType = "String" linkType = "जनक" linkLevel = "1" workItemType = "कार्य">
    <लक्ष्यित नाम = "राज्य" />
    <SourceItem नाम = "राज्य" />
    <मैपिंग>
       लक्ष्यीकरण मैपिंग करें = "हल किया गया" समावेशी = "और">
          <SourceValue> हल किया गया </ SourceValue>
          <SourceValue> बंद </ SourceValue>
          <SourceValue> परित्यक्त </ SourceValue>
       </ मानचित्रण>
    </ मैपिंग>
 </ AggregatorItem> 

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

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

मैंने निम्नलिखित समूहों के उदाहरणों की जांच नहीं की, लेकिन उनके प्रदर्शन के बारे में कोई विशेष संदेह नहीं है।

निम्न उदाहरण स्वचालित रूप से डेवलपर्स और परीक्षकों के कुल अनुमानित कार्य की गणना करता है। परिणाम कार्य तत्व में अनुमानित कार्य क्षेत्र में दर्ज किया गया है।

  <AggregatorItem OperationType = "Numeric" ऑपरेशन = "Sum" linkType = "Self" workItemType = "कार्य">
    <TargetItem नाम = "अनुमानित कार्य" />
    <SourceItem नाम = "अनुमानित देव कार्य" />
    <SourceItem नाम = "अनुमानित परीक्षण कार्य" />
 </ AggregatorItem> 

डेवलपर्स पृष्ठ पर अधिक उदाहरण हैं, लेकिन वे सभी एक ही नस में हैं।

योजनाओं में

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

एक AggregatorItems फ़ाइल संपादक बनाने पर विचार करें।

यह workItemType के लिए एक से अधिक तत्व निर्दिष्ट करना संभव बनाता है।

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

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

यदि प्लगइन काम नहीं करता है

आपने सफलतापूर्वक सब कुछ अनपैक किया है, इसे सही निर्देशिका में स्थापित किया है, सेटिंग्स फ़ाइल को आवश्यकतानुसार संपादित किया है, और यह काम नहीं किया है:

ठीक है, सब कुछ सही ढंग से किया गया है या नहीं यह जांचने के लिए नीचे एक छोटी चेकलिस्ट है:

• आप TFS 2010 का उपयोग कर रहे हैं।
• सभी तत्व अभिभावक-बाल लिंक वाले एकत्रीकरण नियमों में उल्लिखित हैं
• आपने एक आइटम अपडेट किया है जिसके लिए नियम को निष्पादित करना आवश्यक है। TFS एकत्रीकरण केवल तब काम करता है जब आइटम को अपडेट किया गया हो और नियम यह निर्धारित करने में सक्षम था और सभी शर्तों ने काम किया हो। भविष्य में, शायद यह व्यवहार बदल जाएगा।
• आपने AggregatorItems.xml फ़ाइल को अपडेट किया और अपने सर्वर पर सही पता लगाया। इसी समय, परियोजनाओं के संग्रह के नाम के बारे में मत भूलना।
• आपने TFS प्लगइन निर्देशिका में dll और AggregatorItems.xml फ़ाइल दोनों को कॉपी किया है।
• आपने तत्वों, स्रोतों और डेटा सिंक के लिए सही नाम निर्दिष्ट किए हैं।
• सेटिंग फ़ाइल utf-8 एन्कोडिंग में सहेजी गई है। नोटपैड ++ उसे "बोम के बिना utf-8" कहता है। यह एक पूरे के रूप में महत्वपूर्ण नहीं होना चाहिए, लेकिन फिर भी।

किसी भी मामले में, अगर कुछ भी काम नहीं करता है, तो कुछ सरल नियम फ़ाइल बनाएं और फिर से प्रयास करें।

यदि यह काम नहीं करता है, तो यह TFSAggregatorIssues@spamex.com पर डेवलपर्स के लिए कार्य आइटम और एग्रीगेटरइंटरइम्स.एक्सएमएल फ़ाइल की सेटिंग्स को निर्यात करने की सिफारिश की जाती है।

कुल मिलाकर

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