Azure DevOps एक्सटेंशन बनाएं

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

और एक सुबह, टीम लीडर ने मुझसे पूछा: "क्या आप टीएफएस के लिए ऐसा काम कर सकते हैं ताकि बिल्ड से जुड़े टैग इस बिल्ड से गुजरने के बाद निर्दिष्ट टैग को लटका दें?"

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

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

इस लेख में मैं आवश्यक तर्क, विस्तार में पैकेजिंग के कार्यान्वयन के बारे में बात करूंगा। तो अगर आप इस तरह के प्लगइन बनाने में रुचि रखते हैं, तो बिल्ली में आपका स्वागत है।

सबसे अधीर के लिए: जीथूब और बाजार पर एक तैयार विस्तार।



Azure DevOps में फ़िल्टर बनाने की क्षमता है जो आपको बोर्ड पर विभिन्न रंगों में मास्क को रंगने की अनुमति देता है।




हम ऐसे कार्यों में रुचि रखते हैं:

• पूरा
• परीक्षण के वातावरण में डाला
• अभी तक QA को सत्यापित नहीं किया गया है

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

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

आवश्यक शर्तें

एक्सटेंशन विकसित करने के लिए, हमें चाहिए:

1. पसंदीदा आईडीई
2. स्थापित टाइपस्क्रिप्ट + नोड.जेएस + एनपीएम (अब मैंने संस्करण 3.5.1 \ 12.4 \ 6.9.0 स्थापित किया है)
3. tfx-cli - पैकेजिंग विस्तार के लिए पुस्तकालय (npm i -g tfx-cli)।

-G ध्वज की उपस्थिति पर ध्यान दें

Microsoft के पास कुछ अच्छे दस्तावेज हैं जिनमें वे सिर्फ सबसे ऊपर हैं और बताते हैं कि किस तरह का विस्तार करना है। इसके अलावा, उसी तरह बिल्ड \ रिलीज़ कार्य बनाने के लिए एक डॉक है।

मेरी राय में, कुछ बिंदुओं को विस्तार से बताने या समझाने के दृष्टिकोण से दोनों लेखों में कमियां हैं, इसलिए मैं उन पर ध्यान केंद्रित करके उन बिंदुओं पर ध्यान केंद्रित करूंगा जो वास्तव में मुझे स्पष्ट नहीं लग रहे थे।

आम तौर पर, आप काफी बड़ी संख्या में भाषाओं में बिल्ड \ रिलीज़ स्टेप लिख सकते हैं। मैं टाइपस्क्रिप्ट पर एक उदाहरण दूंगा।

टाइपस्क्रिप्ट क्यों?

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

परियोजना की संरचना

|--- README.md |--- images |---extension-icon.png |--- TaskFolder (     build\release step'a) |--- vss-extension.json ( ) 

अगला, हमें बिल्ड स्टेप ए के कार्यान्वयन के लिए पुस्तकालय स्थापित करने की आवश्यकता है

1. सीडी टास्क फोल्डर
2. एनपीएम init
3. npm azure- पाइपलाइनों-टास्क-लिब - save && npm स्थापित @ प्रकार / नोड - save-dev && npm स्थापित @ प्रकार / q -save-dev स्थापित करें
4. tsc - इनिट

विकास का विस्तार

सबसे पहले, TaskFolder के अंदर, हमें task.json फ़ाइल बनाने की आवश्यकता है - यह स्वयं बिल्ड चरण के लिए प्रकट फ़ाइल है। इसमें सेवा की जानकारी (संस्करण, निर्माता, विवरण) शामिल है, जो सभी आदानों के लॉन्च और कॉन्फ़िगरेशन के लिए एक वातावरण है, जिसे हम भविष्य में फॉर्म पर देखेंगे।

मैं प्रलेखन में इसकी संरचना का अधिक विस्तार से अध्ययन करने का प्रस्ताव करता हूं।
हमारे मामले में, फॉर्म पर 2 इनपुट'ए होगा - वह टैग जो हम काम की वस्तुओं में जोड़ देंगे, और पाइपलाइन प्रकार (निर्माण या रिलीज़) का विकल्प।

 "inputs": [ { "name": "pipelineType", "type": "pickList", "label": "Specify type of pipeline", "helpMarkDown": "Specify whether task is used for build or release", "required": true, "defaultValue": "Build", "options":{ "Build": "Build", "Release": "Release" } }, { "name": "tagToAdd", "type": "string", "label": "Tag to add to work items", "defaultValue": "", "required": true, "helpMarkDown": "Specify a tag that will be added to work items" } ] 

नाम से, नीचे दिए गए कोड में हम प्रत्येक इनपुट के मूल्य का उल्लेख करेंगे।
TaskFolder में एक index.ts बनाएँ और कोड का पहला टुकड़ा लिखें

 import * as tl from 'azure-pipelines-task-lib/task'; async function run() { try { const pipelineType = tl.getInput('pipelineType'); } catch (err) { tl.setResult(tl.TaskResult.Failed, err.message); } } run(); 

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

आसान क्वेरी निष्पादन के लिए लाइब्रेरी स्थापित करें

 npm install request --save && npm install request-promise-native --save 

इसे index.ts में जोड़ें

 import * as request from "request-promise-native"; 

हम फ़ंक्शन को कार्यान्वित करते हैं, जो वर्तमान बिल्ड से संलग्न कार्य आइटम प्राप्त करेंगे

प्राधिकरण के बारे में थोड़ा सा

REST API एक्सेस करने के लिए, हमें एक्सेसटोकन प्राप्त करने की आवश्यकता है

 const accessToken = tl.getEndpointAuthorization('SystemVssConnection', true).parameters.AccessToken; 

अगला, हेडर प्राधिकरण को "बियरर $ {accessToken}" पर सेट करें

हम निर्माण से संबंधित कार्य आइटम प्राप्त करते हैं।

Url Azure DevOps सर्वर और TeamProject नाम निम्न प्रकार से पर्यावरण चर से प्राप्त किया जा सकता है

 const collectionUrl = process.env["SYSTEM_TEAMFOUNDATIONCOLLECTIONURI"]; const teamProject = process.env["SYSTEM_TEAMPROJECT"]; 

 async function getWorkItemsFromBuild() { const buildId = process.env["BUILD_BUILDID"]; const uri = `${collectionUrl}/${teamProject}/_apis/build/builds/${buildId}/workitems`; const options = createGetRequestOptions(uri); const result = await request.get(options); return result.value; } 

 function createGetRequestOptions(uri: string): any { let options = { uri: uri, headers: { "authorization": `Bearer ${accessToken}`, "content-type": "application/json" }, json: true }; return options; } 

URL द्वारा GET अनुरोध के जवाब के रूप में

 ${collectionUrl}/${teamProject}/_apis/build/builds/${buildId}/workitems 

हमें इस तरह का JSON मिलता है

 { "count": 3, "value": [ { "id": "55402", "url": "https://.../_apis/wit/workItems/55402" }, { "id": "59777", "url": "https://.../_apis/wit/workItems/59777" }, { "id": "60199", "url": "https://.../_apis/wit/workItems/60199" } ] } 

प्रत्येक url के लिए, उसी REST API के माध्यम से, आप कार्य आइटम पर डेटा प्राप्त कर सकते हैं।

फिलहाल, हमारी रन पद्धति इस प्रकार है।

रिलीज़ से कार्य आइटम प्राप्त करने की विधि लगभग पहले से वर्णित के समान है।

 async function run() { try { const pipelineType = tl.getInput('pipelineType'); const workItemsData = pipelineType === "Build" ? await getWorkItemsFromBuild() : await getWorkItemsFromRelease(); catch (err) { tl.setResult(tl.TaskResult.Failed, err.message); } 

अगला कदम प्राप्त कार्यों में से प्रत्येक के लिए टैग का वर्तमान सेट प्राप्त करना और हमारे द्वारा निर्दिष्ट एक को जोड़ना है।

चलो रन विधि जोड़ें:

 async function run() { try { const pipelineType = tl.getInput('pipelineType'); const workItemsData = pipelineType === "Build" ? await getWorkItemsFromBuild() : await getWorkItemsFromRelease(); workItemsData.forEach(async (workItem: any) => { await addTagToWorkItem(workItem); }); } catch (err) { tl.setResult(tl.TaskResult.Failed, err.message); } } 

आइए कार्य आइटम में एक टैग जोड़ने पर विचार करें।

सबसे पहले, हमें उस टैग को प्राप्त करने की आवश्यकता है जिसे हमने फॉर्म पर इंगित किया था।

 const tagFromInput = tl.getInput('tagToAdd'); 

क्योंकि 2 कदम पीछे हमें प्रत्येक कार्य आइटम के एपीआई के लिए यूआरएल मिला, फिर उनकी मदद से हम आसानी से वर्तमान टैग की सूची का अनुरोध कर सकते हैं:

 const uri = workItem.url + "?fields=System.Tags&api-version=2.0"; const getOptions = createGetRequestOptions(uri) const result = await request.get(getOptions); 

जवाब में, हमें यह JSON मिलता है:

 { "id": 55402, "rev": 85, "fields": { "System.Tags": "added-to-prod-package; test-tag" }, "_links": { "self": { "href": "https://.../_apis/wit/workItems/55402" }, "workItemUpdates": { "href": "https://.../_apis/wit/workItems/55402/updates" }, "workItemRevisions": { "href": "https://.../_apis/wit/workItems/55402/revisions" }, "workItemHistory": { "href": "https://.../_apis/wit/workItems/55402/history" }, "html": { "href": "https://..../web/wi.aspx?pcguid=e3c978d9-6ea1-406f-987d-5b03e24973a1&id=55402" }, "workItemType": { "href": "https://.../602fd27d-4e0d-4aec-82a0-dcf55c8eef73/_apis/wit/workItemTypes" }, "fields": { "href": "https://.../_apis/wit/fields" } }, "url": "https://.../_apis/wit/workItems/55402" } 

हम सभी पुराने टैग लेते हैं और उनमें एक नया जोड़ते हैं:

 const currentTags = result.fields['System.Tags']; let newTags = ''; if (currentTags !== undefined) { newTags = currentTags + ";" + tagFromInput; } else { newTags = tagFromInput; } 

हम आइटम एपी को काम करने के लिए एक पैच अनुरोध भेजते हैं:

 const patchOptions = getPatchRequestOptions(uri, newTags); await request.patch(patchOptions) function getPatchRequestOptions(uri: string, newTags: string): any { const options = { uri: uri, headers: { "authorization": `Bearer ${accessToken}`, "content-type": "application/json-patch+json" }, body: [{ "op": "add", "path": "/fields/System.Tags", "value": newTags }], json: true }; return options } 

विधानसभा और पैकेजिंग का विस्तार

जो कुछ भी होता है, उसकी सुंदरता के लिए, मैं tsconfig.json में कंपाइलर ऑउंस में जोड़ने का प्रस्ताव करता हूं

 "outDir": "dist" 

। अब, अगर हम टास्क फोल्डर के अंदर tsc कमांड को निष्पादित करते हैं, तो हमें डिस्टर्ब फोल्डर मिलता है, जिसके अंदर index.js होगा, जो अंतिम पैकेज पर जाएगा।

क्योंकि हमारा index.js डिस्ट फ़ोल्डर में स्थित है और फिर हम इसे अंतिम पैकेज पर भी कॉपी करेंगे, हमें task.json को थोड़ा ठीक करना होगा:

 "execution": { "Node": { "target": "dist/index.js" } } 

फ़ाइल अनुभाग में vss-extension.json में, आपको स्पष्ट रूप से घोषित करना होगा कि अंतिम पैकेज में क्या कॉपी किया जाएगा।

 "files": [ { "path": "TaskFolder/dist", "packagePath": "TaskFolder/dist" }, { "path": "TaskFolder/node_modules", "packagePath": "TaskFolder/node_modules" }, { "path": "TaskFolder/icon.png", "packagePath": "TaskFolder/icon.png" }, { "path": "TaskFolder/task.json", "packagePath": "TaskFolder/task.json" } ] 

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

ऐसा करने के लिए, कमांड चलाएँ:

  tfx extension create --manifest-globs ./vss-extension.json 

निष्पादन के बाद, हमें एक * .vsix फ़ाइल मिलती है, जिसे आगे TFS में स्थापित किया जाएगा।

PS * .vsix फ़ाइल मूल रूप से एक सामान्य संग्रह है, आप इसे आसानी से 7-ज़िप के माध्यम से खोल सकते हैं, उदाहरण के लिए, और देखें कि आपको जो कुछ भी चाहिए वह वास्तव में अंदर है।

कुछ सुंदरता जोड़ें

यदि आप पाइप लाइन में जोड़ते समय अपने बिल्ड स्टेप का चयन करते समय एक छवि रखना चाहते हैं, तो इस फ़ाइल को टास्क के बगल में रखा जाना चाहिए। json और नामित icon.png। आपको टास्क में कोई बदलाव करने की जरूरत नहीं है।

आप vss-extension.json में एक अनुभाग जोड़ सकते हैं:

 "icons": { "default": "images/logo.png" } 

यह चित्र स्थानीय एक्सटेंशन की गैलरी में प्रदर्शित किया जाएगा।

एक्सटेंशन स्थापित करें

1. Tfs_server_url / _gallery / manage पर जाएं
2. अपलोड एक्सटेंशन पर क्लिक करें
3. पहले प्राप्त * .vsix फ़ाइल को फेंकने के लिए पथ या drag'n'drop निर्दिष्ट करें
4. एक्सटेंशन के संदर्भ मेनू में सत्यापन पास के बाद, खुलने वाले पृष्ठ पर दृश्य एक्सटेंशन का चयन करें, उस संग्रह का चयन करें जिसमें आप इसे स्थापित करना चाहते हैं
5. इस एक्सटेंशन के बाद, आप इसका उपयोग शुरू कर सकते हैं।

निर्माण step'a का उपयोग करना

1. अपनी जरूरत की पाइप लाइन खोलें
2. Add stepaa को ऐड करें
3. हम विस्तार की तलाश कर रहे हैं
   
   
   
4. हम सभी आवश्यक सेटिंग्स इंगित करते हैं
   
   
5. जीवन का आनंद लें :)

निष्कर्ष

इस लेख में मैंने दिखाया कि कैसे Azure DevOps के लिए एक प्लग-इन बनाया जाए, जो स्वचालित रूप से रिलीज़ के लिए कार्यों के लिए सही टैग डालता है। सहकर्मियों ने इसे पाइपलाइन में बनाया, जो खिड़कियों और लिनक्स बिल्ड एजेंटों दोनों पर चलता है।

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

एक बार फिर, मुझे डाउनलोड लिंक : लिंक याद है

हम संशोधन के लिए प्रतिक्रिया और सुझावों के लिए तत्पर हैं :)

पुनश्च

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