Tag Archives: Azure Pipelines

Azure Pipelines: Classic or YAML?

I get this question often: “We’ve been using Azure Pipelines for a while, and really enjoy the WYSIWYG experience of it for building pipeline definitions. But now there’s this YAML-based option as well and seems to be getting the most love. Should I switch? Or what should I use?

The short answer is “it depends” (isn’t that always the answer?).. it depends on whether you’re mid-flight with a project, starting a new one, and what your team’s tolerance is for making such a change.

Let’s do a quick comparison.

Classic vs. YAML

Classic

The classic editor for pipelines has been around since the inception of Azure Pipelines. It’s user friendly in that you simply add in the tasks you want from a visual list, fill in some blanks, and you’re done (I’m simplifying but you get the picture). It’s easy to see what a classic pipeline does, and troubleshooting is a breeze. Need to add a task? Simply search for it, click “add”, and that’s it!

Changes to pipeline definitions are versioned, but not in any useful DevOps way other than being able to see what’s changed. There is always one “live” version of a definition at any given time. So while versioned, you can’t do any kind of review, promotion/demotion, or branching/merging with a classic pipeline.

YAML

YAML on the other hand, isn’t much in the way of being visual. It’s markup/code based. So what? To answer that question, let’s look at what other code stuff you may have and why it’s represented as code.

You probably have application code, right? It defines what your app does. You store it (or should) in a version control repo somewhere. This provides a mechanism to track changes to your app, maintain different releases, and roll back when necessary.

You may have Infrastructure as code (IaC) as well. It defines the infrastructure on which an application will run. It’s also (or at least should be) stored in a repo somewhere, for the same purposes as your app code, but also because it allows you to evolve the infrastructure needs of the application along with the application itself – keeps everything in sync. With me so far?

Think of a YAML pipeline definition as “pipelines as code.” It’s a code-based definition of what your CI/CD workflow does when called upon. By managing your pipeline as code, you can version alongside both the app code and the infrastructure code, keeping everything in harmony. Need to branch your app code? What happens if you do that, and as part of the work you do in said branch the infra needs change? If you’re using IaC, you can modify that code as well and you’re good. But what if the changes also require changing the CI/CD workflow as well? YAML pipelines to the rescue. By keeping as many aspects of your DevOps assets and workflows in a repository as possible, you minimize the complications of deploying from branches, re-work upon merging a PR, etc.

Learning YAML & Migrating from Classic

The good news is that, although more of a learning curve than the classic experience, YAML isn’t crazy hard. You just need to understand the syntax and nuance.

If you’re currently using the classic experience, there are some helpers built into Azure Pipelines to assist you in making the switch to YAML, such as the “Export to YAML” feature as well as the “View as YAML” feature.

Learn more here: