We would like to link a TFS work item to a Release so we can easily, with one click from the Release, open a TFS item that contains more info about this release. Info like Release Notes etc.
Is it possible? A release has these variables that can be set when the release is created but they won't hold a (clickable link).
We cannot link work items for an existing release for now, there's already a user voice submitted here to suggest the feature, you can go and vote it up or submit a new one to achieve that in future release.
However you can link work items from changeset, try below steps:
Associate the work items to a changeset when you check in the changes
Then enable Automatically link new work in this build under Option in the build pipeline. Thus when a build completes successfully, it will create links to all work items linked to associated changes. See Automatic linking work items to builds for details.
Create a release pipeline and set the build which created in step2 as the artifacts source (For CI/CD).
You can also enable Report deployment status to Work for the stages under Option in the release pipeline (For set the repository as artifacts source ), thus when the stage completes, it will create links to all work items linked to associated changes.
Please note that in the release summary, it compares the current release with the previous release and then displays the newly added work items associated with changesets. So if you create two releases with the same artifacts source, then the second release will not include the work items... You can reference this thread for details: In TFS 2018, how do I get linked work items to show up in a release?
Related
I have set up a branch policy for the main branch that requires pull requests and linked workitems.
A build is configured as part of the branch policy.
Once the build for the merge is completed a release pipeline picks up the artifact. The release has "Pull request deployment" activated in the "Pre-deployment conditions"
In the release pipeline I need the information about the linked workitem. Is there a way to get it?
EDIT
At the end I could use the easy way and rely on the branch name that in our team conventions contains the pbi
The answer is still a good one. So I keep the question here
I believe this is possible, though a little awkward. Steps would be as follows:
Get the Build ID associated with the artifact using the Release.Artifacts.{alias}.BuildId variable
Use the Get Build Work Items Refs API to get the list of work items linked to the PR build
I have a build pipeline with a trigger on new branch creation. The trigger works fine with me creating a new branch and linking a workitem task to the new branch.
I have tried to run the query through the API to retrieve the workitem associated to the build but it always comes back blank. I can retrieve the list of workitems in the project no problem.
The URI I am using is:
https://dev.azure.com/{instance}/{project}/_apis/build/builds/{build id}/workitems?api-version=6.0
This returns a blank value. If I remove the "workitems" then I get a list of all the builds with one of the entries matching the build id. The PAT I am using has full access to the project (currently testing so have not been specific for the access).
This is the last step for me to complete and I can piece the whole puzzle.
UPDATE1: I have now noticed that in the pipeline log there is no related work item even though I create the branch from within the work item.
UPDATE2: I notice if I do a commit and associated the work item then the build lists the related work item. Does not appear to work when creating a new branch, only comitting to that new branch
Build pipeline adds related work items by reading the work items associated with the checkout commit.
I have now noticed that in the pipeline log there is no related work item even though I create the branch from within the work item.
When you create the new branch in work item, you need to change the build branch in Build Pipeline.
Then the build will use the newly created branch to build pipeline, the work items will relate to the Build.
When you run the Rest API: Builds - Get Build Work Items Refs, it will show the related work item.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/workitems?api-version=6.0
We use continuous build and deploys up through a test environment, and each changeset is tied to a work item (story). After the build is deployed to an environment, I think we can see every associated story for that build. Question is what has changed, functionally, both for verification/acceptance tests and for release notes, support training, and marketing. This is related to How can I identify which work items/user stories are in a selected build in Azure DevOps? except that we want to know before the candidate moves to a higher level environment and to collect the sum of unique changes since this pipeline last promoted to that environment
For this issue ,you could see related work items in Release stage page. It compares the current release with the previous release and then displays the newly added work items associated with changesets.
Note:If the current release deployed an older artifact, then the difference lists negative work items i.e., the changes that were rolled back from this stage.
In addition,you can also enable Report deployment status to Work for the stages under Option in the release pipeline, thus when the stage completes, it will create links to all work items linked to associated changes.
You can see if this is what you need.For the similar case,please refer to this .
Similar to this question but for Azure DevOps. Going back 6-12 months, I was able to open a deployed Release (or possibly a successful Build, my memory is hazy) in what was then VSTS and view the backlog Work Items associated with it. On that page I was also able to filter on release names so that the list would show me all Work Items associated with any Release from the same Release Definition that was newer than the one I filtered on. This was how I used to put together our user-friendly release notes. It allowed me to view the bugs that'd been fixed, the features that'd been included, and so on. As far as I can tell, this feature no longer exists in Azure DevOps - at least, I can't find it.
The closest I can get is to view a list of Changesets from a particular date in the Changesets pivot, but that's not as comprehensive as a list of Work Items that were completed, and also doesn't tell me which Release those Changesets were included in.
I can also run a Query to show Work Items completed from a particular date but again I don't think I can view what Releases those Work Items were associated with, and even if I could it wouldn't help much unless I could filter Work Items based on the repository branch from which the Release was created.
Does anybody know if there is a way now in Azure DevOps to view the Work Items associated with a particular Release or Build? And, ideally, a list of Work Items associated with any Build or Release created from a specified Build or Release Definition from a particular date (e.g. "Show me all Work Items associated with Builds created from the 'Education Only Version' Build Definition since January 1st").
Howzit
Edit: I just realized this question was long ago... it showed near the top, assuming you have this solution but now
When you deploy a stage you can see all the work items and commits that are linked to commits since the last build that went to that stage.
In Project A, I setup a build to automatically link the build to associated workitems...worked flawless the first time.
In another project - I have a build-definition which does not set the link.
What's curious - a clone of said definition, with some tasks removed (basically just "Upload Artifacts" removed, cause it is just a build-verification test for pull-requests) does set the link.
I even re-created the build-definition from scratch, still no links added sigh
Anybody have any insights on these problems?
Also - I ran the build in "debug" mode, with detailed logs...could not find any information which would be helpful.
Thanks in advance
Johannes Colmsee
Update: there is another task I removed from the "Build-Verification" Build-definition: publish symbols
Update 2: for brand new build-definitions, I will get a warning telling me that the link was not created because too many changesets were associated…for subsequent builds though...no warning, but also no link sigh
Update 3: also - I can manually select the builds for "integrated in build" link in the workitem - so...they could potentially be added automatically too I suppose...
Update 4: the subsequent PullRequest and the following builds all associated OK to the workitems….so it was probably my fault.
The warning message in your Update 2 should be the reason. "Automatically link work" feature compares the changes and work items between the current build and previous build. When the count of changes or work items is more than 200, it will not link. When you create a new build definition and run a build, there is no previous build which means that all the changes and work items in your code repository are calculated. And also if there is no change or no work item linked in the change in the subsequent build, it will not link any work either.