Using Azure DevOps Environments and Approvals for Safer Progressive Delivery

Problem: One‑Click Production Deployments Risk Everything

When a pipeline builds and immediately pushes to production, a single mis‑config or test failure can affect all users. The lack of a pause point turns automation into a liability. The solution is to insert a gate that requires human or automated validation before the code reaches the live environment.

Thesis: Combine Multi‑Stage YAML with Environments to Enforce Gates

Azure DevOps lets you declare build, test, and deploy stages in one YAML file. By attaching deploy jobs to Environments and configuring Approvals and Checks for those environments, you create explicit pause points that protect production.

How Environments Work

An Environment is a logical grouping of deployment targets. It can hold:

• Human approvals – only specified users can click Approve.
• Automated checks – scripts or service hooks that must pass before a stage continues.
• Deployment history – a record of which build ran where.

Environments live under Project Settings > Environments and are independent of the pipeline file.

Writing a Multi‑Stage YAML Pipeline

Use the deploy job type for stages that target environments. The dependsOn keyword ensures stages run only after the previous one succeeds.

stages:
- stage: Build
  jobs:
  - job: Compile
    steps:
    - script: echo 'Building artifacts...'

- stage: DeployStaging
  dependsOn: Build
  jobs:
  - deploy: DeployToStaging
    environment: 'Staging'
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo 'Deploying to Staging...'

- stage: DeployProd
  dependsOn: DeployStaging
  jobs:
  - deploy: DeployToProd
    environment: 'Production'
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo 'Deploying to Production...'

Notice the environment names match those created in the UI. The pipeline will stop at DeployProd until the approval gate is cleared.

Configuring the Approval Gate in the UI

1. Navigate to Project Settings > Environments.
2. Select or create the Production environment.
3. Click the three dots and choose Approvals and checks.
4. Add Approvals and specify users or groups that may approve.
5. Optionally add checks (e.g., a script that verifies a health‑check API).

When the pipeline reaches the production stage, it enters a Pending state. An authorized user must click Approve in the run UI before the job runs.

Variable Groups for Environment‑Specific Secrets

Secrets and configuration values that differ per environment can be stored in a Variable Group. Link the group to the pipeline, and reference variables like $(dbConnectionString). The group can be scoped to a specific environment to avoid accidental exposure.

Trade‑offs and Limitations

• Permissions: Users with project‑level admin rights can bypass approvals. Use the least‑privilege model.
• Server vs. Services: On‑prem Azure DevOps Server lags behind the cloud service in environment features. Verify your server version supports approvals.
• Complexity: Adding environments and gates increases pipeline maintenance overhead. Keep the configuration simple for small projects.

Actionable Checklist

• Create Staging and Production environments.
• Set approvals for Production.
• Write a multi‑stage YAML pipeline that references these environments.
• Link a variable group scoped to each environment.
• Run a test pipeline to confirm the approval gate pauses correctly.

By following these steps, you transform a one‑click deployment into a controlled, auditable process that protects your users and infrastructure.