I have Product backlog item, I am able to see templates from Azure Board UI. I want to use Azure CLI commands to add templates to the product backlog item. I have query to create Backlog which is working fine but I am not getting how to add templates available to the backlog.
I'm afraid there is no such Azure CLI command to add templates to workitems. If you would like that feature, please create a request for this feature here.
I have a setup that requires the repo, CI and CD of the application to live in one Azure DevOps project. Some of the work that is being done on that application is managed at times in a different Azure DevOps project.
I know that I can allow linking and reporting on CD progress to related Work Items. My problem is that it seems to work only when the Work Item is within the same Azure DevOps project that the CD is in.
Does anyone know of a way to get it working across projects?
I have this enabled on the CD pipeline:
Also, when I navigate to the Work Item associated to this Release Pipeline I see this (different Azure DevOps project):
As you can see it does not seem to report on the progress of the associated Release Pipeline. But it does report on the repo that lives in the other Azure DevOps project. Also, if I click on the Release link, it will bring me to the Release of the project where work is being managed and not where the Release Pipeline actually lives.
Does anyone know of a way to get it working across projects?
Of course, this can be achieved, you can refer to the following steps：
Step1: Commit changes to the Repo with Work items.
Note: You can link the work item from another project.
To link work item with repo, there are two methods:
Use #ID in comment.
Select the work item ID.
Step2: Enable the option Automatically link new work in this build in Build pipeline -> Options
Step3: In Rlease Pipeline, you need to select the Report deployment status to Work and
Report deployment status to Boards
The Option Report deployment status to Work will show the release under the link tab.
The Option Report deployment status to Boards will show the release under the Deployment tab.
Based on my test, it could work on work items from another project too.
We have the same enterprise app that we sell to multiple customers. The source for the app is hosted in a private Azure DevOps Repo. But we manage each customer's implementation using a separate project for each customer with it's own work items.
Currently we have no way of linking commits to the Source in the Repo project to work items in the implementation project.
We don't want to have the repo in each implementation since that would be redundant and challenging to keep in sync.
Is there a way to handle this inside DevOps?
Currently we have no way of linking commits to the Source in the Repo
project to work items in the implementation project.
For this issue, when you commit to the source in the Repo project, on the Commit page, you can choose to link to work items in other projects.
Or you can click Add link in the Development field of the work items in other projects.
Then on the Add link page, select the Commit link type, select your source repo, and select the commit you want to link.
My company creates a lot of projects in Azure DevOps, and they all have the same structure -- same members, same permissions. Each project has different Git repositories within it, but that's the only thing (other than the name) that differs between them. It would be helpful to have a template so that everything is set up correctly each time we need a new one.
I don't see a way to do this through the web interface. I have the sense that I could probably do it with a script, but I don't know where to begin with that (including which tool to use). Where should I start?
It looks like there is now a way to do this without the Azure DevOps CLI (as long as your project that you want to template is one of the supported types (Agile, Scrum and Basic)). There is a tool available here that will step you through the process.
There is also an excellent blog post here that gives you an overview.
Yes, you can accomplish most of the configuration by script. For the beginning you might take a look at the Azure Devops CLI, which allows you to perform several actions on Azure Devops, like:
Create projects, Users and configure security
Create repositories, pipelines and set branch permissions
Create and manage work items
...
I have got a project in an old org (from VSTS), that I want to move to my new one.
I can't see any options in Azure DevOps on migrating projects, or any information on the interwebs.
Anyone know how to do it?
If you just need to move repos, you can use the built in clone functions:
Go to the Azure Devops source repo -> Files
Click "Clone"
Choose "Generate Git Credentials"
Create the target repo in the target Azure DevOps
Choose "Import a repository"
Use the URL and credentials from Step 3
Done
This is not supported today. But this feature was planned to develop: make it possible to move a Team Project between Team Project Collections
If your Azure Devops project only tracks code versions using a single Git repo, hence no boards, user stories, tasks, pipelines, etc. then you can do the following:
Clone your project repo.
For example with Visual Studio.
You don't need to clone if you already have a local repo.
Destroy the association with the remote.
For this typically, you need to open a command line prompt in the folder that contains the .git database folder, most likely the solution folder of Visual Studio and type git remote rm origin.
Here is an example using git bash showing the content of the solution folder, including the .git database and the *.sln Visual Studio solution file:
Open the solution with Visual Studio if not already done.
It should now show that you have many commits waiting to be pushed to a remote. For illustration purpose, my toy project only have 8 commits in total.
Click the up arrow and choose your new remote, say a brand new Azure DevOps project, in the organization of your choice, then push.
You are now done cloning the project in another organization. If needed, then destroy the project in the old organization to complete the "move" operation.
There are 3 projects that I know of to achieve this.
A paid for option by Ops Hub -
OpsHub Visual Studio Migration Utility
An open source tool that requires making changes to the work item process template - Azure DevOps Migration tools
An lastly an Unofficial but still written by Microsoft tool to create Azure DevOps project templates - Azure DevOps Demo Generator & extractor tool
With the last one (the Demo Generator) you extract the project as a template, then apply it to the new organisation. As it is a tool for demo's there is no support provided and in my experience it works for simple projects but falls over on anything complex.
Expanding on others' answers, this post regards Pipelines.
Azure DevOps API
Migrating nearly all aspects of a project across organizations is doable, but it is a lot of manual work using the Azure DevOps API. The link below shows you all the end points, variables, etc. From there you'll probably want to write a Power Shell script and do a couple test runs to a dummy Organization.
https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1&viewFallbackFrom=azure-devops-rest-6.0
In App options
If you avoid the API, there is no way to migrate pipelines that preserve build or release history, but you can preserve your configurations and processes by going into your Pipelines and selecting View YAML. From here you can either take this away as notes to recreate the GUI steps in your new org/project location, or actually adopt the YAML standard in your git repository.
I do not believe there is a way to migrate pipeline variables outside of the API. However, you can move the variables to Azure Key Vault and change your pipeline settings (YAML) to reference values from key vault. This is not a large amount of effort and is a nice process improvement.
Lastly, if you have any locally installed pipeline agents for releases, you will need to run the Power Shell script for your new organization on the boxes. Very simple 5m step, but right now the Agent Pools are not sharable across organization.
As #Frederic mentioned in his answer, we can actually easily do it with Visual Studio. I have done this without Visual Studio. The steps involved are below.
Add a User to Both Organization
Configure SSH Key
Update the SSH Key in Source DevOps and Clone the Repository
Check out all the Branches and Tags
Update the SSH Key in the Destination DevOps
Remove Old and Add New Origin
Push all the branches
The commands and detailed explanations can be found here.
BTW, if you need to change the entire Devops Organization tied to your personal Tenant (E.g. VS Enterprise Subscription) and move it to new Tenant, you can change the AAD and point it to the new one e.g. your EA Tenant on Azure commercial cloud.
Before you switch your organization directory, make sure the following statements are true:
You're in the Project Collection Administrator group for the
organization.
You're a member or a guest in the source Azure AD and a
member in the destination Azure AD
You have 100 or fewer users in
your source organization. Otherwise you will have to open a support ticket.
You may have to add the users back in destination org if they do not exist becuase they will loose access the moment you switch the AAD.
you could just download as a zip file and then download it to the destination repo