{"id":38930,"date":"2020-04-20T11:50:38","date_gmt":"2020-04-20T18:50:38","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/premier-developer\/?p=38930"},"modified":"2020-03-27T12:04:18","modified_gmt":"2020-03-27T19:04:18","slug":"how-to-retrieve-all-work-items-associated-with-a-release-pipeline-using-azure-devops-api","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/how-to-retrieve-all-work-items-associated-with-a-release-pipeline-using-azure-devops-api\/","title":{"rendered":"How to retrieve all work items associated with a release pipeline using Azure DevOps API"},"content":{"rendered":"

App Dev Manager Mahendar Madhavaram<\/a> and Premier Field Engineer Eduardo Bottcher<\/a> explore how to retrieve all work items associated with a release pipeline using Azure DevOps API.<\/p>\n

\n

One of the greatest features of using Boards, Repositories and Pipelines in Azure DevOps is the ability to link and associate work items to all sorts of coding and deployment elements such as commits, branches, pull requests, builds and releases. With those associations in place, it is possible to identify, for example, what work items were deployed on a given release or track what lines of code were involved in the last deployment to production. Those are all very valuable and strategic information you can use for auditing purposes or troubleshooting data to help diagnose an incident. Out of the Box, the tool can display those relations in various screens, like the Build Summary page or the Work Item Form but you can also use the Azure DevOps Rest API to pull that information for your specific scenarios. The good news is that Azure DevOps provides multiple endpoints and technologies to connect and query data.<\/p>\n

In this article we are going to learn how to retrieve all work items associated with a release pipeline using the Azure DevOps API.<\/p>\n

Setting up the Work Items Associations<\/h2>\n

The goal here is to make sure the build and release pipeline definitions are configured to associate work items during the whole CI\/CD process. As code gets committed and built, tasks, user stories, bugs and other work items links should be created to each operation. That is the foundation to be able to report on those links later in this article.<\/p>\n

The first step is to make sure every code change is associated with a work item. This will link the work items with commits, branches and Pull requests. You can accomplish that by enabling a build policy to check for linked work items.<\/p>\n

    \n
  1. Click the Repositories and the Branches Menu in the Azure DevOps Portal\n. \"A<\/li>\n
  2. Locate in the branch list the one you are going to use to build from, typically that should be your master branch, and click the options icon. Select Branch policies.\n\"A<\/li>\n
  3. Check the option \u201dCheck for linked work items\u201d. Click Save changes.\n\"A<\/li>\n<\/ol>\n

    The next step is to enable the build definition to create links to all work items linked to associated changes when a build completes successfully.<\/p>\n

      \n
    1. Select your build pipeline definition and click Edit on the top right corner of the page. \"A<\/li>\n
    2. In the Options Tab, enable the option \u201cAutomatically link new work in this build\u201d. Click Save. \"A<\/li>\n<\/ol>\n

      The last step is to configure the release pipeline to link those work items to the release when a stage is completed.<\/p>\n

      1 \u2013 Select your release pipeline definition and click Edit on the top right corner of the page. \"A<\/p>\n

      2 \u2013 In the Options Tab, select the Integrations Section and enable the option \u201cReport deployment status to Work Stages. You have the flexibility to choose which environments to associate. \"A<\/p>\n

      To test this process, create a branch, make changes to a file, commit those changes, create a pull request, merge it, build and then deploy it using your release pipeline. If the associations are being created and the work items are being linked properly, you should be able to see that information in the Details tab under the Deployment section on the Work item page, as shown in the image below:<\/p>\n

      \"A<\/p>\n

      Also, you can view all work items that were associated to a given release by going to the Summary page of a release run. It should look like this:<\/p>\n

      \"A<\/p>\n

      Let\u2019s say, for example, that we need to list all work items associated to code changes that got deployed to production in the past 3 months. Since none of those pages will give you that type of visualization because they display one release run at a time, you will need to retrieve that data programmatically from Azure DevOps. Let\u2019s evaluate some options:<\/p>\n

      Queries<\/strong><\/p>\n

      Although you can use some work item links types as part of your query parameters, by design it is not possible to query by commits, builds or releases. The reason is those links are treated internally in the tool as a relation object instead of the conventional link objects such as Parent and Child link types.<\/p>\n

      Azure DevOps Analytics<\/strong><\/p>\n

      Currently, the v3.0-preview of the OData Endpoint doesn\u2019t expose all the release pipeline information we need for this report. However, it is expected that eventually this will be incorporated as part of the data model. For more information, refer the article on Extending Analytics with OData (Preview)<\/a><\/p>\n

      Rest API<\/strong><\/p>\n

      The solution is to use the Azure DevOps REST API but there are many ways to invoke it depending on your client application type and authentication method. The link Azure DevOps Services REST API Reference<\/a> has some useful information to help you decide which client technology to use.<\/p>\n

      Writing the client application to call the API<\/h2>\n

      For this article, we will build a console application in C# to call the Azure DevOps Rest API using the Client API library. This will greatly simplify our code and avoid long and extensive json parsing and manipulation when compared to using the HttpClient object. You can still make direct calls if you prefer, though.<\/p>\n

      Here is the code:<\/p>\n

      \/\/ Copyright \u00a9 Microsoft Corporation.  All Rights Reserved.\r\n\/\/ This code released under the terms of the \r\n\/\/ Microsoft Public License (MS-PL, http:\/\/opensource.org\/licenses\/ms-pl.html.)\r\n\r\nusing System;\r\nusing System.Linq;\r\nusing Microsoft.TeamFoundation.Build.WebApi;\r\nusing Microsoft.TeamFoundation.WorkItemTracking.WebApi;\r\nusing Microsoft.VisualStudio.Services.Common;\r\nusing Microsoft.VisualStudio.Services.ReleaseManagement.WebApi.Clients;\r\nusing Microsoft.VisualStudio.Services.WebApi;\r\n\r\nnamespace GetRelatedWorkItemsAppPoc\r\n{\r\n    class Program\r\n    {\r\n        internal const string azureDevOpsOrganizationUrl = \"https:\/\/dev.azure.com\/{yourorganization}\/\";\r\n        internal const string pat = \"{yourtoken}\";\r\n        internal const string projectName = \"{yourprojectname}\";\r\n\r\n        static void Main(string[] args)\r\n        {\r\n            var connection = new VssConnection(new Uri(azureDevOpsOrganizationUrl), new VssBasicCredential(string.Empty, pat));\r\n\r\n            var startDate = new DateTime(2019, 9, 5, 18, 0, 0, DateTimeKind.Utc);\r\n            var endDate = new DateTime(2019, 12, 5, 23, 30, 0, DateTimeKind.Utc);\r\n\r\n            var releaseClient = connection.GetClient<ReleaseHttpClient>();\r\n            var buildClient = connection.GetClient<BuildHttpClient>();\r\n            var wiclient = connection.GetClient<WorkItemTrackingHttpClient>();\r\n                              \r\n            var releaseList = releaseClient.GetReleasesAsync(project: projectName, minCreatedTime: startDate, maxCreatedTime: endDate).Result;\r\n            \r\n            \r\n            Console.WriteLine($\"Organization: {azureDevOpsOrganizationUrl}\");\r\n            Console.WriteLine($\"Project Name: {projectName} \\n\");\r\n            Console.WriteLine($\"Searching for Deployments from {startDate} to {endDate} UTC\\n\");\r\n\r\n            if (releaseList.Count > 0)\r\n            {\r\n                foreach (var releaseItem in releaseList)\r\n                {\r\n                    var release = releaseClient.GetReleaseAsync(project: projectName, releaseId: releaseItem.Id).Result;\r\n\r\n                    Console.WriteLine($\"Deployment Report for {release.Name}\");\r\n                    var deploymentArtifact = release.Artifacts.FirstOrDefault();\r\n\r\n                    if (deploymentArtifact != null)\r\n                    {\r\n                        var buildRunId = Convert.ToInt32(deploymentArtifact.DefinitionReference[\"version\"].Id);\r\n                        var buildVersion = deploymentArtifact.DefinitionReference[\"version\"].Name;\r\n\r\n                        var workItemList = buildClient.GetBuildWorkItemsRefsAsync(project: projectName, buildRunId).Result;\r\n                        Console.WriteLine($\"{String.Empty.PadLeft(5)} List of workitems associated to Build {buildVersion} \");\r\n\r\n                        foreach (var workitem in workItemList)\r\n                        {\r\n                            var wi = wiclient.GetWorkItemAsync(id: Convert.ToInt32(workitem.Id), expand: Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models.WorkItemExpand.Relations).Result;\r\n                            Console.WriteLine($\"{String.Empty.PadLeft(10)} {wi.Id} - {wi.Fields[\"System.Title\"]} \");\r\n                        }\r\n                    }\r\n                    else\r\n                    {\r\n                        Console.WriteLine(\"Unable to Locate Artifact for this deployment\");\r\n                    }\r\n                    Console.WriteLine(\" \");\r\n                }\r\n            }\r\n            else\r\n            {\r\n                Console.WriteLine(\"No Deployments found for this period.\");\r\n            }\r\n        }\r\n              \r\n    }\r\n}\r\n<\/pre>\n
      For this sample to work, replace the variable strings with your organization URL, PAT token and project name.<\/p>\n
      The first thing the program does after the authentication steps is to list all releases that occurred in the past 3 months.<\/p>\n
      According to the API, the associated work items are not linked directly to a release run. Instead, they are linked through the build that generated the artifact that was used as source for the release pipeline. Therefore, the application had to load the artifact data to identify the build run and then get a list of all work items associated to that build. You could go one level further and even query all the commits associated with the work items to get to the file names.<\/p>\n
      Conclusion<\/h2>\n
      I hope you got inspired to explore new ways to interact with Azure DevOps and experience how easy and straightforward it is to pull information from the Azure DevOps using REST API.<\/p>\n
      References<\/h2>\n