Azure Pipelines: Classic Editor VS. YAML

In this post, the two configuration options in Azure Pipelines will go head to head in an epic battle…

Ok, maybe this won’t be an epic battle, just a friendly pro and con list between the two.

Classic Editor

  • User friendly
  • Mature feature set for CD
  • One live version of each definition
  • No longer the default

User friendly: Even a cave man knows how to click around in a browser. No need to learn Yet Another Markup Language (YAML).

Mature feature set for CD: There are a lot of really useful features that are not yet available in YAML: steps for manual validation, automated checks (gates) between stages, ability to scope environments to multiple projects (Deployment Groups can do this).

One live version of each definition: It can be difficult to isolate changes to definitions because you effectively have one live version of each definition. To make changes without affecting others, you could clone the definition, make changes, test, then manually add the changes to the live version. This is kind of a pain and it doesn’t include a review process for others to have visibility into the changes before they’re applied. Task Groups have a feature to draft and preview changes, but they’re not always in use and can create unnecessary complexity for simple pipelines.

No longer the default: When creating new definitions, the classic editor is no longer the default option. It’s now hidden towards the bottom, making it harder to find. YAML is the future, hint, hint, nudge, nudge.

Let’s make it really difficult for users to NOT use YAML. Muahhahaha!


  • Easy to collaborate
  • Repository portability
  • CI/CD industry standard
  • Steeper learning curve
  • CD features not at parity with classic (yet)

Easy to collaborate: You can use the same branching & merging strategy and workflow as your applications. Topic branches can be used to isolate pipeline changes, then pull requests can be used to review the changes with teammates before the changes get merged.

Repository portability: You can place your YAML file alongside your application code, making your repository more “portable”. Pipelines are a black box for users that don’t have access to your CI/CD platform. By cloning a repository that has a YAML pipeline, others know exactly what is takes to build and deploy the application.

CI/CD industry standard: most CI/CD tools support YAML (GitHub Actions, GitLab CI, Travis CI, Drone) C’mon, everybody else is doing it!

Steeper learning curve: It may take users longer to get the hang of working with YAML files. However, the Task Assistant can help. There is also a Visual Studio Code Azure Pipelines extension to assist with syntax highlighting and IntelliSense. Still afraid of YAML? You could start with the classic editor, then make the switch to YAML using the “View YAML” button later down the road:


There really isn’t a clear winner. As with most of these types of decisions, it depends.

If: You’re new to Azure Pipelines OR require advanced CD features OR prefer working in a GUI over code.
Then: Start with the classic editor, then make the switch to YAML when you’re ready.
Else: Use YAML.

3 thoughts on “Azure Pipelines: Classic Editor VS. YAML

  1. I just ran into an issue with the YAML pipelines. We are following GitFlow with some rules that are strictly enforced, for example the release needs to have work items associated. In GitFlow you create a release branch to start a release, the new branch triggers a new build and the environments can do a diff to check what work items are associated with the new release. In YAML, not so much, since the commit has already been build by CI elsewhere (the develop branch) and the work item associated there or even further back (feature branch) the work item does not get associated with the new run and the QA people will not let the release be deployed since they don’t have the work item traceability.

Leave a Reply

Your email address will not be published. Required fields are marked *