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.
Related
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.
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 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.
We are using TFS 2017 as our project management system, and I'm missing a functionality that seems to be available in most other solutions: it's the ability to regroup tasks/user stories/bugs/etc into a single set (called Milestone in Github, or Version in JIRA) to be able to track the work done and remaining for the release of a defined set of functionalities.
Does TFS provides an equivalent to those Milestones/Versions?
It sounds like a sprint / iteration to me.
Since Iteration path is hierarchical you can create nodes that represent Releases or Milestones (versions are a bad idea) and then have your Working Time as Sprints under them.
Release 1
Release 1\Sprint 1
Release 1\Sprint 2
Release 1\Sprint 3
Release 1\Sprint 4
release 2
Release 2\Sprint 1
You can then have a variable number of Sprints inside of each Release. If you are in VSTS you get good visual planning tools to help you plan across releases or sprints...
Another options would be to add a custom field for the data that you want to track.
Usage of Iterations is typically the way to go. However, you can also use Tags and Queries to create release or milestone lists that are either flat or hierarchical. If the queries are flat, you can create graphs/charts and dashboard them as well.
Delivery Plans also add yet another alternative to help visualize timelines and create markers for important dates/milestones.