Another benefit of using Git in your repos is being able to use YAML pipelines instead of the classic ones.
And what is the most significant difference? An image is worth a thousand words, so here’s a classic pipeline:
And here’s a YAML pipeline:
Yes, a YAML pipeline is code-based! There’s still a minimal GUI for the tasks, but everything on your pipeline is defined in a file in YAML format.
While it may look a bit harder to define everything in code, it’s also more powerful.
Classic pipelines are still 100% supported, but as with TFVC, there are fewer improvements for them, and I’d recommend moving to YAML pipelines.
Almost everything you did in classic pipelines (both Build and Release) is doable in YAML:
- Builds & multi-stage releases: classic had separate build and release pipelines. In YAML you use multi-stage pipelines (stages → jobs → steps) to do CI and CD in one file.
- Environments and deployment targets: environments give you deployment history and are the place where you add approvals/checks.
- Approvals, gates & checks: classic pipelines had pre/post approvals and gates. In YAML you add approvals and checks to environments (branch control, required template, evaluate artifact, business hours, approval, REST/Azure Function, Azure Monitor alerts, exclusive lock, etc.).
- Variables & secrets: YAML supports variable groups (including Key Vault-linked) and inline variables/parameters.
- Triggers & schedules: YAML pipelines have CI/PR triggers and schedules in the file.
In the next sections, we’ll learn how to create a build pipeline, a release pipeline, and how to add stages, schedules, and triggers in code.
