Azure DevOps: Classic Pipelines vs YAML Pipelines

1. What are Classic and YAML Pipelines?

Azure DevOps supports two main approaches to creating CI/CD pipelines: Classic Pipelines and YAML Pipelines.

Both automate activities such as building, testing, publishing, and deploying applications. The main difference is how the pipeline is defined, maintained, and version-controlled.

Classic Pipeline (GUI-based)

A Classic Pipeline is created using the Azure DevOps graphical user interface (GUI).

• Configure pipelines by selecting tasks and entering values.

• No YAML knowledge is required.

• Suitable for beginners, simple pipelines, and existing legacy projects.

• Build and release pipelines are commonly configured separately.

YAML Pipeline (Pipeline as Code)

A YAML Pipeline is defined using a YAML file, typically named azure-pipelines.yml, stored in the Git repository.

• Pipeline configuration is written as code.

• Supports CI/CD using stages, jobs, steps, and tasks.

• Changes can be reviewed and version-controlled through Git.

• Supports reusable templates, parameters, and conditions.

• Recommended for most new CI/CD implementations.

2. Differences Between Classic and YAML Pipelines

3. How Do They Work?

Classic Pipeline

Azure DevOps Portal
        |
        v
Create Classic Pipeline
        |
        v
Select Git Repository
        |
        v
Add Build Tasks Using UI
        |
        v
Configure Triggers
        |
        v
Save and Run Pipeline
        |
        v
Build → Test → Publish
        |
        v
Classic Release Pipeline
        |
        v
Deploy to Environment

YAML Pipeline

Developer
    |
    v
Git Repository
    |
    v
azure-pipelines.yml
    |
    v
Commit and Push
    |
    v
Pipeline Trigger
    |
    v
Build Stage
    |
    v
Test Stage
    |
    v
Deploy Stage
    |
    v
Application Deployed

The YAML approach keeps the pipeline definition alongside the application source code.

4. Example: YAML Pipeline for ASP.NET Core

trigger:
  - main

pool:
  vmImage: 'windows-latest'

steps:
  - task: UseDotNet@2
    displayName: 'Install .NET SDK'
    inputs:
      packageType: 'sdk'
      version: '8.0.x'

  - script: dotnet restore
    displayName: 'Restore Packages'

  - script: dotnet build --configuration Release --no-restore
    displayName: 'Build Application'

  - script: dotnet test --configuration Release --no-restore
    displayName: 'Run Tests'

Explanation:

• trigger: Runs the pipeline when code is pushed to main.

• pool: Specifies the agent environment.

• UseDotNet@2: Installs the required .NET SDK.

• dotnet restore: Restores NuGet packages.

• dotnet build: Compiles the application.

• dotnet test: Executes unit tests.

This example implements CI. Deployment stages can be added to implement CD.

5. Why Are YAML Pipelines Preferred for New CI/CD Implementations?

The major reasons are:

1. Version Control: Pipeline definitions are stored in Git. Every modification can be tracked and reverted.

2. Code Review: Pipeline changes can go through Pull Requests and approval policies.

3. Reusability: YAML templates allow multiple applications to share common build and deployment logic.

4. Consistency: The same pipeline configuration can be used across multiple projects and environments.

5. Maintainability: Pipeline changes can be managed using normal development practices.

6. Security: Pipeline changes can be reviewed, and access to protected resources can be controlled.

7. Multi-stage CI/CD: Build, test, and deployment activities can be defined in a single pipeline.

Microsoft also recommends starting with YAML for new pipelines.

Microsoft Learn

+1

6. Advantages and Disadvantages

Important: YAML does not mean every setting must be written in code. Some settings, such as environment approvals, are configured through the Azure DevOps portal.

7. Interview Questions and Answers

Q1. Which pipeline would you choose for a new project?

I would choose a YAML Pipeline because it supports Pipeline as Code, Git version control, Pull Request reviews, reusable templates, and multi-stage CI/CD.

Q2. Can we migrate a Classic Pipeline to YAML?

Yes. We can recreate the Classic build and deployment configuration in YAML, validate the new pipeline, and gradually migrate. Not every Classic release feature has an identical YAML equivalent.

Q3. Can YAML Pipelines support production approval?

Yes. Azure DevOps supports approval checks through environments, allowing authorized users to approve production deployments.

Q4. Are Classic Pipelines deprecated?

Classic Pipelines are still supported. However, Microsoft recommends YAML for new implementations.

Q5. Can Classic and YAML Pipelines coexist?

Yes. An organization can continue running existing Classic Pipelines while implementing new applications using YAML.

8. Key Interview Points

• Classic = GUI-based pipeline configuration.

• YAML = Pipeline as Code.

• Classic commonly separates build and release pipelines.

• YAML supports CI/CD within one multi-stage definition.

• YAML files are stored and version-controlled in Git.

• YAML templates improve reusability and standardization.

• Both approaches support CI/CD, but YAML is generally preferred for new projects.

Interview-ready answer:

"Classic Pipelines are configured through the Azure DevOps graphical interface, whereas YAML Pipelines are defined as code and stored in Git. YAML Pipelines are preferred for modern CI/CD because they support version control, Pull Request reviews, reusable templates, better maintainability, and multi-stage deployment. For new projects, I would prefer YAML Pipelines, while existing Classic Pipelines can continue running or be migrated gradually."

Reference: Microsoft Learn — YAML vs Classic Pipelines.