Migrating existing (entire) Azure DevOps pipeline to YAML based pipelines (in bulk)

Question

I would like to move the existing Azure DevOps pipelines to YAML based for obvious advantages. The problem is there are many of these and each one has many jobs.

When I click around in Azure DevOps, the "View YAML" link only appears for one job at a time. So that's gonna be a lot of manual work to view YAMLs for each pipeline x jobs and move that to code.

But for each pipeline there seems to be a way to "export" the entire pipeline in json. I was wondering if there is a similar way to at least dump the entire pipeline as YAML if not an entire folder.

If there is an API which exports the same then even better.

Answer 1

Until now, what we supported is what you see, use View YAML to copy/paste the definition of agent job. There has another workaround to get the entire definition of one pipeline is use the API to get the JSON from a build definition, convert it to YAML, tweak the syntax, then if needed, update the tasks which are referenced.

• First, use Get Build Definition api to get the entire definition of one pipeline.

• Invoke JSON to YAML converter. Copy/paste the JSON of definition into this converter.

• Copy the YAML to a YAML editor of Azure Devops. Then the most important step is tweak the syntax.

Replace the refName key values with task names and version. For this, you can go our tasks source code which opened in github, built in tasks can be found there(note: please see the task.json file of corresponding task)

Noted: Use this method has another disadvantage that you need very familiar with YAML syntax so that you can tweak the content which convert from JSON successfully.

Answer 2

This is done and there is blog post about exporting pipelineas YAML on devblogs

It's it worth to mention that the new system knows how to handle every feature listed here:

• Single and multiple jobs
• Checkout options
• Execution plan parallelism
• Timeout and name metadata
• Demands
• Schedules and other triggers
• Pool selection, including jobs which differ from the default
• All tasks and all inputs, including optimizing for default inputs
• Job and step conditions
• Task group unrolling

In fact, there are only two areas which we know aren’t covered.

Variables

Variables defined in YAML “shadow” (hide) variables set in the UI. Therefore, we didn’t want to export them into the YAML file in case you need an ability to alter them at runtime. If you have UI variables in your Classic pipeline, we mention them by name in the comments to remind you that you need to configure them in your new YAML pipeline definition.

Timezone translation

cron schedules in YAML are in UTC, while Classic schedules are in the organization’s timezone. Timezone handling has a lot of sharp edges, so we opted not to try to be clever. We export the schedule without doing any translation, so your scheduled builds might be off by a certain number of hours unless you manually modify them. Here again, we make a note in the comments to remind you.

But there won't be support for release pipelines:

No plans to do so. Classic RM pipelines are different enough in their execution that I can’t make the same strong guarantees about correctness as I can with classic Build. Also, a number of concepts were re-thought between RM and unified YAML pipelines. In some cases, there isn’t a direct translation for an RM feature. A human is required to think about what the pipeline is designed to accomplish and re-implement it using new constructs.

Answer 3

I tried yamlizr https://github.com/f2calv/yamlizr It works pretty well for exporting Release Pipelines, except it doesn't export out Pre/Post deployment conditions. We use these for Approval gates. So hopefully in a future release it will be supported. But per Microsoft they won't support the export to YAML for Release Pipelines it sounds like. https://devblogs.microsoft.com/devops/replacing-view-yaml/#comment-2043