In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
Fill in a changelog dynamically
Stop deployment if there are an issues part of the Release that are not Done
Retrieve version numbers
Question: Is there a VSTS equivalent?
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.{YourFieldName}' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
Related
We've been using environments for a while now for our dev and test instances. I like being able to go to the environment and seeing the commits and work items associated with the particular build/release but can't find a way to export them. Does anyone know of a way to export the workitems?
Using environments you also loose the ability to see which build/release a ticket went out in or have I missed something?
Your first and second question, kind of, have the same answer.
In short, you don't want to be using Environments to view which work items are associated with a release.
Azure DevOps has a built-in mechanism to view work items directly within the Release or Pipelines page (Depending on whether you're using classic or YAML).
Here is a great guide published by Microsoft regarding how work pipeline-based work item linking works, as well as how to retrieve work items associated with a release:
https://devblogs.microsoft.com/premier-developer/how-to-retrieve-all-work-items-associated-with-a-release-pipeline-using-azure-devops-api/
Update:
Specifically regarding how to view linked work items in Pipelines. You'll want to look under "Related":
Clicking on "x work items" will show you the full list of work items:
After reading through the End-to-End traceability documentation our team is finding it difficult to accomplish the final step in this list:
Developers create a branch or PR on a work item (in this case, a Task)
When the PR is completed and the branch merged, the work item shows the build
When the build artifact is released, the work item shows the deployment environments
All of that works great, but the final step is:
Show the builds and deployments on all parent tasks of the work item i.e., the Feature work item and the User Story work item.
Is that not possible? Or is there a rule or template that we could write that would automatically copy development links up the hierarchical chain so that developers and business can see the traceability across all associated work items?
Conversely, are we intended to manually link all development links to all work items?
Based on my understanding, you want parent work items to display builds and deployments tracked by child work items.
Testing on my side, the parent work items will not show the builds and deployments tracked by the child work items. DevOps currently does not support such feature.
We recommend that you could request this feature on: https://developercommunity.visualstudio.com/report?space=21&entry=suggestion. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.
Is it possible to add additional mapping to Get Sources at runtime?
Like in a prejobexecution task?
We are currently using a Powershell script that determines which additional mappings to setup based on iteration, area and different business requirements, maps them to the current workspace and then runs tf get.
This works, however, the changesets and work items from the additional mappings are not linked to the run.
We have also tried a different approach, where a “starter”-pipeline runs the scripts and modifies another pipeline (updates the tfvcMapping) and then invokes it using a build completion trigger.
All changesets and work items are linked, however, the approach does not seem right.
Add additional mappings to Get Sources at runtime (Azure DevOps pipeline - TFVC)
I have encountered a issue very similar to yours before (I use git). Personally, I prefer your second solution, which saves all the linked information (changesets and work items) at the cost of an additional pipeline.
For the first way, just as you test, we will lose some relevant information, which is not what we expected. Although we can use the checkout command to get the latest changesets, we cannot simply complete it for workitems, because it is done by Azure devops. It is difficult for us to obtain the associated workitems through changesets and associate them with our build.
The solution for me, we create a pipeline(as you said starter-pipeline) to invoke the REST API Definitions - Update to update the get source for another pipeline, then hen add build completion trigger:
PUT https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=5.1
Check the similar request body here.
Hope this helps.
I come from using Rally and Pivotal Tracker. In both I could assign work items to Releases as a planning tool, and to have a historical record of those work items that were deployed.
Even with all the highly-specific guidance from Microsoft about Azure DevOps, it is silent how to organize work against future Releases. I can't see a place to even associate a work item to a Release. Is there something I am missing in all the documentation, or is there some workaround strategy more robust than just using tags to pro-actively plan against releases? Or is Microsoft's expectation that I use some separate product management tool to manage work items against Releases?
There are multiple techniques employed to accomplish this, not "one way":
use a parent iteration path that groups the iterations you plan against a certain release. This works best when you completely finish one release before starting the next. Otherwise, it usually becomes a mess with multiple active iterations.
Backlog Iteration
+ Release 1.0
+ Sprint 1
+ Sprint 2
+ Sprint 3
+ Release 2.0
+ etc
-
use tags for releases. Add a tag [Release 1.0] top all work items that are included in that release, this is one of the most flexible options.
use Azure Pipelines to keep track of which Work Items were associated to which Git commits and thus was included in which Build artifact. Track the build artifacts across environments to see which work items were deployed to an environment by looking at the intermediate builds.
add a custom work item field to the work item types you want to track. You can change the work item process being used and you can add a field to the work items in which you can specify the release name/number. There are custom controls available that can scope the version numbers to a specific list or can fetch the allowed values from any REST API.
Azure DevOps is more flexible in the usage patterns as you can see, but it also means that sometimes you need to "figure out what works best" for your team.
Another extension you may be interested in is the Bravo Notes extension. Or one of the other extensions that can generate Release Notes based on you work item data, commits and/or pipeline artefacts.
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.