CI and CD in a Single Multi-Stage YAML Pipeline

1. What is it?

Yes. Azure DevOps supports implementing both Continuous Integration (CI) and Continuous Delivery/Deployment (CD) in a single multi-stage YAML pipeline.

A multi-stage YAML pipeline combines building, testing, publishing, and deploying an application into one pipeline definition, typically stored in azure-pipelines.yml.

Purpose:

Automate the complete application delivery process.
Avoid maintaining separate CI and CD pipelines.
Reuse build artifacts across deployment environments.
Support approvals, conditions, and environment-specific deployments.

2. How Does It Work?

Consider an ASP.NET Core Web API application deployed to Azure App Service.

Developer
    |
    v
Git Repository (main)
    |
    | Push / Merge
    v
azure-pipelines.yml
    |
    v
STAGE 1: BUILD (CI)
    |
    |-- Restore NuGet Packages
    |-- Build .NET Application
    |-- Run Unit Tests
    |-- Publish Build Artifacts
    |
    v
STAGE 2: DEV DEPLOYMENT (CD)
    |
    |-- Download Build Artifacts
    |-- Deploy to DEV
    |
    v
STAGE 3: UAT DEPLOYMENT (CD)
    |
    |-- Approval (if configured)
    |-- Deploy to UAT
    |
    v
STAGE 4: PRODUCTION (CD)
    |
    |-- Manual Approval
    |-- Deploy to Production
    |
    v
Deployment Completed

Important: The application is built once, and the same artifact is promoted through DEV, UAT, and Production. This avoids rebuilding the application separately for each environment.

3. Example: Multi-Stage YAML Pipeline

The following is a simplified example for an ASP.NET Core Web API application deployed to Azure App Service.

trigger:
  - main

pool:
  vmImage: 'windows-latest'

stages:

# Stage 1: Continuous Integration
- stage: Build
  displayName: 'Build and Test'

  jobs:
  - job: BuildJob
    steps:

    - task: UseDotNet@2
      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 Unit Tests'

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

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

# Stage 2: Deploy to DEV
- stage: Deploy_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'

# Stage 3: Deploy to UAT
- stage: Deploy_UAT
  dependsOn: Deploy_DEV

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

# Stage 4: Deploy to Production
- stage: Deploy_PROD
  dependsOn: Deploy_UAT

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

In this example, replace the project path, service connection, and App Service names with your actual values. The DEV, UAT, and PROD environments must be configured in Azure DevOps. Approval checks are configured separately on those environments.

4. Important YAML Keywords

Keyword	Purpose
`trigger`	Defines when the pipeline starts
`stages`	Defines CI/CD stages
`jobs`	Groups execution activities
`steps`	Defines individual tasks or scripts
`dependsOn`	Controls stage dependencies
`condition`	Controls conditional execution
`deployment`	Defines a deployment job
`environment`	Associates deployment with an environment
`publish`	Publishes build artifacts
`strategy`	Defines deployment execution strategy

5. Continuous Delivery vs Continuous Deployment

Both can be implemented using a multi-stage YAML pipeline.

Continuous Delivery	Continuous Deployment
Application is ready for release	Application is automatically released
Production approval may be required	No manual production approval
Controlled production deployment	Fully automated deployment

For example:

Continuous Delivery:

Build → Test → DEV → UAT
                       |
                  Manual Approval
                       |
                       v
                  Production


Continuous Deployment:

Build → Test → DEV → UAT → Production
                              |
                       Automatically

6. Advantages and Disadvantages

Advantages

Single YAML file for CI/CD.
Better visibility into the complete delivery process.
Reuse the same build artifact across environments.
Supports approvals, conditions, and deployment history.
Easier version control and maintenance.

Disadvantages

Large YAML files can become difficult to maintain.
Complex dependencies require careful configuration.
Incorrect conditions can trigger unintended deployments.
Requires knowledge of YAML syntax and deployment jobs.

For large projects, reusable YAML templates can help reduce complexity.

7. Interview Questions and Answers

Q1. Can we implement CI and CD in a single YAML pipeline?

Yes. Azure DevOps supports multi-stage YAML pipelines where the Build stage performs CI, and subsequent deployment stages perform CD.

Q2. Is it mandatory to create separate CI and CD pipelines?

No. Both can be implemented in a single multi-stage pipeline. Separate pipelines are optional and may be preferred when release schedules or ownership differ.

Q3. How do you prevent deployment to Production without approval?

Configure an approval check on the Production environment in Azure DevOps. The pipeline waits for approval before executing the protected deployment stage.

Q4. What happens if the Build stage fails?

By default, dependent deployment stages will not execute because the Build stage has failed.

Q5. Do we need to rebuild the application for each environment?

No. The recommended approach is to build once and promote the same artifact across DEV, UAT, and Production, using environment-specific configuration.

8. Key Interview Points

CI and CD can be implemented in one multi-stage YAML pipeline.
CI performs restore, build, test, and artifact publishing.
CD deploys the published artifact to target environments.
dependsOn controls stage execution order.
condition controls whether a stage executes.
Deployment jobs support environments and deployment history.
Environment approvals protect production releases.

Interview-ready answer:

"Yes. Azure DevOps supports CI and CD in a single multi-stage YAML pipeline. We can define separate stages for Build, Test, DEV, UAT, and Production deployment. The CI stages compile and test the application and publish artifacts, while CD stages deploy those artifacts to different environments. We use dependsOn for execution order, conditions for controlling deployments, and environment approvals for production releases. This approach provides centralized pipeline management, traceability, and automated software delivery."