Azure DevOps: Classic Release Pipeline and Migration to YAML

1. What is a Classic Release Pipeline?

A Classic Release Pipeline is a GUI-based deployment pipeline in Azure DevOps used to automate application deployment across environments such as Development, UAT, and Production.

It is mainly used for Continuous Delivery (CD).

In the traditional Classic approach, two separate pipelines are commonly used:

• Classic Build Pipeline (CI): Restores, builds, tests, and publishes application artifacts.

• Classic Release Pipeline (CD): Takes the published artifacts and deploys them to different environments.

Example: ASP.NET Core Web API

Developer
    |
    v
Git Repository
    |
    v
CLASSIC BUILD PIPELINE (CI)
    |
    |-- Restore NuGet Packages
    |-- Build Application
    |-- Run Unit Tests
    |-- Publish Artifacts
    |
    v
BUILD ARTIFACT
    |
    v
CLASSIC RELEASE PIPELINE (CD)
    |
    v
DEV Environment
    |
    v
UAT Environment
    |
    |-- Manual Approval
    v
PRODUCTION Environment
    |
    v
Deployment Completed

The Release Pipeline consumes artifacts generated by the Build Pipeline and deploys them to the configured environments.

2. How Does a Classic Release Pipeline Work?

Step 1: Create a Build Pipeline

Navigate to:

Azure DevOps → Pipelines → Pipelines

Create a build pipeline to compile the application, run tests, and publish artifacts.

Step 2: Create a Classic Release Pipeline

Navigate to:

Azure DevOps → Pipelines → Releases → New Pipeline

Select an appropriate deployment template or start with an empty job.

Step 3: Configure Artifacts

Connect the Release Pipeline to the Build Pipeline.

For example:

Build Pipeline: MyWebApi-CI
Artifact Name: drop

Enable the continuous deployment trigger if releases should be created automatically when a new artifact is available.

Step 4: Configure Deployment Stages

Create stages for the environments:

DEV → UAT → PRODUCTION

Each stage can contain deployment tasks such as:

• Azure App Service deployment

• IIS Web App deployment

• Azure SQL Database deployment

• PowerShell scripts

Step 5: Configure Approvals

Configure pre-deployment approvals for sensitive environments.

For example, the Production deployment may require approval from a Release Manager.

Step 6: Execute the Release

Once the release is triggered, Azure DevOps deploys the selected artifacts according to the configured stages, conditions, and approvals.

3. Classic Release Pipeline vs YAML Deployment Pipeline

Important: Classic Release Pipelines are still supported. Migration to YAML is not mandatory.

4. How Can Classic Pipelines Be Migrated to YAML?

Migration means converting the existing GUI-based build and release configurations into YAML definitions.

There is no complete one-click migration that automatically converts every Classic Release Pipeline feature into an equivalent YAML pipeline.

The recommended approach is to migrate the configuration step by step.

Migration workflow

EXISTING CLASSIC PIPELINES
          |
          v
Review Build and Release Definitions
          |
          v
Identify Tasks, Variables, Artifacts
          |
          v
Create azure-pipelines.yml
          |
          v
Convert Build Tasks to YAML
          |
          v
Convert Release Stages to YAML
          |
          v
Configure Service Connections
          |
          v
Configure Environments and Approvals
          |
          v
Test YAML Pipeline in DEV
          |
          v
Validate UAT and Production
          |
          v
Switch to YAML Pipeline
          |
          v
Retire Classic Pipelines

Step 1: Review Existing Classic Pipelines

Identify the existing configuration:

• Build tasks and deployment tasks

• Artifact names and locations

• Environment-specific variables

• Service connections

• Deployment triggers

• Approval requirements

• Agent pools and deployment targets

Step 2: Convert the Classic Build Pipeline

For example, a Classic Build Pipeline containing .NET restore, build, test, and publish tasks can be converted to YAML.

trigger:
  - main

pool:
  vmImage: 'windows-latest'

stages:
- stage: Build
  displayName: 'Build Application'

  jobs:
  - job: BuildJob
    steps:

    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '8.0.x'

    - script: dotnet restore
      displayName: 'Restore'

    - script: dotnet build -c Release --no-restore
      displayName: 'Build'

    - script: dotnet test -c Release --no-restore
      displayName: 'Test'

    - script: dotnet publish MyWebApi/MyWebApi.csproj -c Release -o $(Build.ArtifactStagingDirectory)/publish
      displayName: 'Publish'

    - publish: $(Build.ArtifactStagingDirectory)/publish
      artifact: drop

Step 3: Convert Classic Release Stages to YAML

Classic deployment stages can be represented as YAML stages containing deployment jobs.

For example, append this DEV deployment stage to the previous YAML:

- stage: Deploy_DEV
  displayName: 'Deploy to DEV'
  dependsOn: Build

  jobs:
  - deployment: DeployDev
    environment: 'DEV'

    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'MyAzureConnection'
              appType: 'webApp'
              appName: 'my-api-dev'
              package: '$(Pipeline.Workspace)/drop'

The deployment job automatically downloads the current pipeline's artifacts when using the deploy lifecycle hook.

Additional stages can be created for UAT and Production.

Step 4: Migrate Variables and Secrets

Classic variables can be converted to YAML variables.

variables:
  buildConfiguration: 'Release'
  environmentName: 'DEV'

For sensitive information, use Azure DevOps secret variables, Variable Groups, or Azure Key Vault rather than storing secrets directly in YAML.

Step 5: Configure Environment Approvals

In Classic Releases, approvals are configured on release stages.

In YAML, approvals are generally configured on protected resources such as environments.

Navigate to:

Azure DevOps → Pipelines → Environments → PROD → Approvals and checks

Add the required approvers.

Note: Environment approvals are not defined directly inside azure-pipelines.yml.

Step 6: Validate and Switch

Before retiring the Classic Pipeline:

1. Execute the YAML pipeline in DEV.

2. Verify build artifacts and deployment results.

3. Validate UAT and Production deployments.

4. Verify approvals, variables, and service connections.

5. Disable the old pipeline triggers after successful validation.

This avoids duplicate or unexpected deployments during migration.

5. Important Migration Considerations

Some Classic features do not have exact one-to-one YAML equivalents. For example, Classic Deployment Groups typically require redesign using YAML environments with virtual machine resources.

6. Advantages and Disadvantages of Migration

Advantages

• CI and CD can be managed in a single YAML pipeline.

• Pipeline definitions are stored in Git.

• Pipeline changes can be reviewed through Pull Requests.

• YAML templates improve reusability.

• Easier standardization across applications.

• Better traceability between source code and pipeline changes.

Disadvantages

• Requires knowledge of YAML syntax.

• Existing deployment configurations may need redesign.

• Complex Classic pipelines may require significant testing.

• Incorrect migration can interrupt existing deployments.

7. Interview Questions and Answers

Q1. What is a Classic Release Pipeline?

A Classic Release Pipeline is a GUI-based Azure DevOps pipeline used to deploy build artifacts to environments such as DEV, UAT, and Production.

Q2. What is the difference between Classic Build and Classic Release Pipelines?

Classic Build Pipelines perform CI activities such as compiling, testing, and publishing artifacts. Classic Release Pipelines perform CD activities by deploying those artifacts.

Q3. Can we migrate Classic Release Pipelines to YAML?

Yes. We can convert Classic deployment stages, tasks, variables, and conditions into YAML. Approvals and protected resources must be configured appropriately.

Q4. Is there an automatic migration tool?

Azure DevOps provides ways to inspect or export YAML for some Classic build tasks and definitions, but there is no universal one-click conversion for complete Classic Release Pipelines.

Q5. Can Classic and YAML Pipelines run simultaneously?

Yes. They can coexist during migration. However, deployment triggers should be carefully managed to prevent both pipelines from deploying the same application unintentionally.

8. Key Interview Points

• Classic Build Pipeline = CI

• Classic Release Pipeline = CD

• Multi-stage YAML Pipeline = CI + CD

• Classic Releases are configured using the Azure DevOps GUI.

• YAML pipelines store pipeline definitions in Git.

• Migration requires converting tasks, stages, variables, triggers, and deployment configurations.

• Production approvals can be configured using Azure DevOps Environments.

• Test the YAML pipeline before retiring the Classic Pipeline.

Interview-ready answer:

"A Classic Release Pipeline is a GUI-based Azure DevOps deployment pipeline that takes artifacts from a build pipeline and deploys them to environments such as DEV, UAT, and Production. To migrate it to YAML, we first review the existing build and release configurations, convert build tasks and deployment stages into YAML, configure variables, service connections, and environment approvals, and then validate the new pipeline. Once the YAML pipeline works successfully, we can retire the Classic Pipeline. YAML is preferred because it supports Pipeline as Code, version control, reusability, and multi-stage CI/CD automation."