I inherited a project a while back that uses Azure DevOps Pipelines for deployment and when I want to edit the pipeline I have access to a wizard to walk through the tasks, triggers, variables, options, etc.. I then set up a completely separate project for a different organization and when I go to create a new pipelines it's only allowing me to use a YAML script. I don't see a way to run through the wizard.
Also, in the previous project under Pipelines I have sub menus for Pipelines and Environments. In the project I just set up I don't have these choices, only Builds. So it seems like I may be using an older version in the original project, I'm not sure and I can't seem to find a way to change the version.
Is this wizard no longer available for new projects? Is there a setting somewhere or something I am missing to gain access to it or do I have to use YAML only from this point on? If that is the case, is there a way to upgrade the old project to this version (I want to stay consistent)?
Is this wizard no longer available for new projects?
No, you just facing the different design of azure devops.
You can only create the YAML.
The page you can see the tasks, triggers or other tabs is the design of Classic editor pipeline.
Please choose Use the classic editor after you new pipeline.
Click Continue after select the source (the repository and the branch) for your project.
At the next step, you can choose Empty job, also you can add some tasks.
Note: do not select Configure as code. It is YAML.
Now, you can see the tabs like tasks, variables, triggers and etc.
Could not seen Pipelines and Environments.
These two tabs are the new UI design which published in recent sprints. And we provide it by enable Multi-stage pipelines in
Preview features panel.
I assume you did not enable this feature and just saw Builds there.
Click your head account which located in right corner, then choose Preview features:
Then enable Multi-stage pipelines.
After enable it and close the panel, this page will be re-load automatically. Then you will see Pipelines and Environments in the left wizard panel.
Related
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 an ImageVault website that we do not develop ourselves. But want version management in TFS and be able to publish against tests and production servers.
It does not need to be built because it is already finished.
How should you set up a building when you should not build anything?
Is it possible to set up a pipeline without having a building?
It is possible to set up a pipeline that doesnot build your project. You project is built by the build tasks in the pipeline. You can just disable or exclude the build tasks from your pipeline if you donot want your project be built.
You can also create an empty pipeline without any tasks inside. You can follow below steps to create an empty pipeline.
1,Sign in to your Azure DevOps organization and navigate to your project.
2,In your project, navigate to the Pipelines page. Choose the Pipelines tab and click new pipeline on the top right corner of the page.
3,Walk through the steps of the wizard by first selecting the location of your source code.(You can create a classic UI pipeline by choosing "Use the classic editor to create a pipeline without YAML".)
4,Then choose to start with An Empty Job under Select a template
With above steps, a pipeline without build tasks is created. You can then add some utility tasks like copy file task, publish artifacts task etc. Utility tasks donot do the building work.
You might need to add some utility tasks like publish build artifacts tasks if you want to deploy release pipeline.
Check here to learn more about creating your pipeline
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
...
Our main project is hosted and managed on VSTS online. We are managing the work using Features, User Stories and tasks. In addition, the code is managed and stored in Repos. We are working with pipelines and such for CICD. Last, we installed some extensions downloaded from the marketplace.
Currently, we are running on the build-in Agile process. We would like to create an inherit process and move the project to it. I’ve done that in the past but without the project using CICD.
The question is, can we do that safely without harming or endangering our code and CICD operations?
Thanks
The CI/CD processes not related to the Work Item process. you can move to inherited process template without harming or endangering your code and your CI/CD pipelines.
Unless you touch the work items during the build (with custom scripts/API) and change fields etc. so you need to update the scripts (e.g. you change a field called "A" and in the new template is "B").
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