YAML and Classic UI in Azure DevOps Pipelines

In this post we are aiming to clarify the advantages of one over the other in a daily use from a development team point of view.

With the current model that we are used to use through the Classic Azure DevOps Pipelines UI, the only way of achieving a continuous integration and continuous delivery process (CI/CD from now on), is to send a pull request to the main branch that merge our changes with the rest of our project code. This will trigger (if it is configured for it) what is known as build. So, through some tasks that we will have configured in our build pipeline, the project code will be compiled among other needed tasks like tests, files modifications, PowerShell scripts and so on. This way we get as result a new item called artifact linked to this build run. This artifact will be used by a process or processes of release for deploying or updating our changes in the environments that we have configured.

At this point a new figure appears that is the release stages, one for each environment where we want to deploy the artifact, with its own variables, tasks configurations and triggers.


Currently, the only way of setting up all these processes, is by a two separated user interfaces, one for the build and other for every release that uses the artifacts generated by that build.

With all this said, you can see that we are a bit tied up in our developments. Despite this Classic UI has more features than the ones shown here, we constantly are finding situations where we are pushed to making alternative processes, so we achieve the needed results. For instance, we can find the case where we have code in more than one repository and we have two builds configured, one for each one because we cannot configure a build that uses both repositories with Classic UI. This situation forces us to generate two different artifacts by these two builds chained one after the other.

So, you can imagine how tedious is to apply a change of one value for every task of every stage in a release. Tons of clicks. Developers do not like clicks…
Jokes aside, all this clicking and waiting for a web page to load menus and settings are translated into a lot of time wasted along the sprint.

With YAML we can have all these processes in a unique text file with this format (YAML Ain't Markup Language). This file can be modified from our preferred text editor and added later to our project code through the version control that we were using. This way we can change all our processes of CI/CD, with build changes, releases modifications and so on with just a simple pull request of the YAML file, things that we were not able to fulfil with Classic UI.


For this reason, we can observe two important advantages: one for sure is the improvement of speed when applying changes, and the other is the use of a version control system applied to our CI/CD process.

We can see the state of the pipeline’s definitions in the past. We can restore that state. We can merge our changes with the ones created by our teammates. We have a branching system for testing stuff without breaking the main process. And this is just the beginning because this is still work in progress.

Another important reason to migrate or incorporate YAML Pipelines as the backbone of our CI/CD process is that Classic UI will be deprecated sooner than later by Microsoft, as we can see in some movements done in this direction. It is a fact that YAML pipelines are the default when creating a new pipeline and the option for changing to classic is a bit less accessible than before.



On the other hand, we still have good things to say about Classic UI. Due to this still being a work in progress, possibly we may need some features in our CI/CD processes that are not yet implemented via YAML Pipeline, so we can be forced to use third party tasks created by the community, or scripts created by us, or simply use our beloved Classic UI. This last option will be less and less used with time because as we can see in this table, we have the majority of functionalities covered by now. We can also take a look at the current roadmap of Azure DevOps and check how the new features are being implemented and what is coming next.

Without doubt, transitioning to YAML must be part of our focus, not only for the fact that is the way to go for new pipelines by Microsoft, but because of the amount of time that can save us on a daily basis once we learn to use its full potential.

In further posts we could have a look at our transition process to YAML itself, showing actual examples of this functionalities like for instance the use of templates where we can define the common parts of our pipelines or the fact itself of generating a build and release in the same file.

Do you want to take a closer look at this? Check the official Azure DevOps Pipelines documentation.