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:
Related
Since the process of one A/B test usually takes multiple sprints I would like to add another board in which I can add the A/B tests (as F.E. features). User stories for one sprint can then be added to a specific sprint for my team (which consists of a few specialists and a developer). This way I am able to overview the status (research phase, test , code writing, running, analysis, etc.) of all tests in one overview. I have not been able to find out how this is possiblie within Azure Devops, or if there is a work around. Can anyone help me?
My team also works in projects other than A/B tests, which means we cannot use the boards section.
Unless there is a hidden way to add another board to a team?
You could Copy or clone a work item to add the user stories or tests to a new boards. Open the user story you want to clone, then click Create copy of work item and choose whether to include exist links, attachments and child work items. After creating, change the Area and Iteration to your target boards.
Update
In Azure DevOps you can only create boards by creating a team. The team board is created as a side-effect of creating the team. Please refer to Manage and configure team tools and Configure and customize Azure Boardsfor details.
After creating and configuring a new team, you could see the boards in the dropdown list.
I have problem with configuration of AzureDevOps process.
My goal is simply automate work items - when work item changes state to done or is in state done on certain board I want to transfer it on other board.
I tried to achieve this by applying custom rules in my organization. Example:
I navigate to Organization Settings, select Process then I select process from list (is inherited from Scrum parent). Then I select bug (for example) and go to rules tab.
Here is screen of my configuration
Both Board no.1 and Board no.2 exist as Team Projects. I've added clearing assign to field and this one works properly.
I wondering if there is much easier way to automate moving work items through boards or team projects on status change.
I wondering if there is much easier way to automate moving work items
through boards or team projects on status change.
For this issue, I am afraid there is no easier way to achieve this requirement. Azure Devops has provided a built-in custom rule function to achieve this. This is already a very easy way.
In addition, we can also achieve this through the azure logic app, but this needs to be set in the azure portal. I don’t think it will be more convenient than custom rules.
To move work items to another project, you must be a member of the Project Administrators group or be granted explicit permissions to move work items.
I have been tasked with figuring out to solve this issue. I am working on a project that uses TFVC in Azure Devops and when a check-in is made the system adds that comment to the discussion thread on the work item. What setting can I change to turn that off?
UPDATED:
I created a test TFVC project in a separate DevOps account that I had with no extensions installed. Checked in changes, a link was added to the Development sections as expected but just like described above it was also added to the discussion, see screenshot. So this appears to be default behavior so how do we turn it off?
As far as I know, you cannot turn this feature off once you have linked the checkin with the work item.
Does TFVC in Azure DevOps automatically write the check-in comment to
the discussion for a work item?
For this issue, the answer is no. The comment added in Check in will be used as the title of the changeset(TFVC) and will not be automatically written to the discussion of the work item.
Changesets will be linked to the Development field of the work item to drive development.
Does TFVC in Azure DevOps automatically write the check-in comment to the discussion for a work item?
Obviously not.
Automatically write check-in comments to the discussion of work items is not applicable to all users, so MS does not add it as the default behavior.
And as test, I could not found this issue on my side, and you could also to check this issue on the other organization or new organization.
As a bold guess, your organization may have one extension installed and these behaviors are performed by this extension, like Work Item Autosave. But I could not sure it, you need to check your extensions one by one, Organization Settings->Extensions.
If you find that extension, you can disable or change the settings to disable this feature.
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.
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.