What is the difference between Classic and YAML pipelines in Azure DevOps?

Think of the difference between Classic and YAML pipelines like the difference between configuring a car's settings through a touchscreen infotainment system versus writing a configuration file that completely defines the car's behavior. The touchscreen is intuitive for beginners and shows you all available options visually, but you cannot version control your preferences, share them across multiple cars, or review changes before applying them. The configuration file requires learning a syntax, but once written it can be stored in Git, reviewed in pull requests, copied across vehicles, and rolled back to any previous version if something goes wrong.

Classic pipelines were Azure DevOps's original pipeline authoring experience. You create them through the web portal by adding tasks from a visual catalog, configuring each task's properties through form fields, and arranging them in stages and jobs using drag-and-drop. Classic pipelines store their configuration in Azure DevOps's internal database, not in the source repository. This means the pipeline definition lives separately from the code it builds, creating several problems: pipeline changes cannot be reviewed in pull requests alongside code changes, there is no version history showing who changed what and when, you cannot branch the pipeline definition alongside a feature branch that needs different build steps, and replicating the same pipeline across multiple repositories requires manual recreation.

YAML pipelines solve these problems by defining the entire pipeline as an azure-pipelines.yml file committed to the repository root. The YAML file specifies triggers, stages, jobs, steps, variables, and conditions using a structured syntax. Because the file lives in the repository, it benefits from all Git workflows: feature branches can modify the pipeline alongside code changes, pull requests show pipeline modifications for review, commit history tracks every change with attribution, and the pipeline definition always matches the code version being built. When you check out a historical commit, you get exactly the pipeline that was used at that point in time.

YAML pipelines also unlock advanced capabilities unavailable in Classic pipelines. Template references allow extracting common pipeline patterns into shared files that multiple pipelines include, enabling standardization across an organization. Conditional insertion lets pipelines dynamically include or exclude stages based on branch names, variables, or expressions. Multi-stage pipelines define build, test, and deploy stages in a single file with approval gates between stages. Extends templates provide a locked-down pipeline structure that project teams fill in without modifying security-critical steps. These features make YAML pipelines essential for organizations managing dozens or hundreds of repositories that need consistent CI/CD patterns.

The production gotcha is that Classic pipelines still have a few capabilities not yet available in YAML, particularly around release pipeline features like deployment groups, manual intervention tasks with timeout, and some legacy task versions. Organizations migrating from Classic to YAML must audit these capabilities and find YAML equivalents. Another common mistake is treating YAML pipelines like Classic pipelines: creating one monolithic file instead of leveraging templates and stages. Teams should start with a template library that defines organizational standards, then have each repository's YAML file reference those templates with project-specific parameters. Microsoft has also announced that Classic pipelines will eventually be deprecated, making YAML the only supported authoring format for new pipelines.