I want to reorganize my variable groups in Azure DevOps, but before I delete any variable groups I want to make sure they are not used anymore. Also I need to link the newly created groups to old releases.
I could go over all release definitions and check which definition is linked to which variable groups, but there should be a more easy way for me show if a variable group still has linked releases. But I cannot seem to find that overview.
Is there an overview like above of will this be a pain in the ... to reorganize?
I don't see it available either, from the front-end or documented as available from the API. I think your only option is the one you mentioned to loop over the definitions to validate.
Looking at Task groups, they included a References tab which is probably what you want just on the Variable group. I'd recommend creating a feature request for this on the developer community.
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:
I want to restore the state my project was in 11/10/2021 into another temporary project (not the one I am currently using), so I can only grasp the order of work items from Backlogs from Boards for that day. I did not delete the project. I just changed the Area Paths for Teams and the order of work items changed. I just want to have a reference in a separate temporary project, so I can compare work items order between them and restore correct one to the actual backlog.
Doing something like this is going to be quite tricky, I think that the closest you will come to doing this will be to create a new project and then try to use the open-source migration tools at https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration. We used an earlier version of this for an Azure DevOps carveout from another tenant, and it worked well, but we didn't have your "restore-to-point-in-time" use case.
I think that what you're going to need to do is use the ReplayRevisions on the WorkItemMigration class, and then you're probably going to need to write some custom WIQL to get only what you're looking for. It's even conceivable you might need to extend this to get the functionality you want.
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 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.
We have a project that often has the exact same work flow needed.
We have a feature that includes detailed work items, along with very helpful descriptions.
Is there not a way to take a current Feature and duplicate it along with all of the work items?
I have tried using templates but that has not worked out.
I tried Copy Work Item and checked 'Include existing links' but it does not copy the Related Work, which is what I need.
To further clarify I would like to duplicate a Feature, along with its Product Backlog Items and their Tasks.
You would be able to use powershell and VSTS REST API to achieve this copying. A sample powershell is available in the thread here
You can modify that and create a script to support your needs.