7.5 YAML Environments, Checks & Deployment Approvals

7.5 YAML Environments, Checks & Deployment Approvals

Variables configure a deployment; environments govern it. A YAML environment is the named deployment target that carries approvals, automated checks and deployment history, and its checks are evaluated before any agent is dispatched.

1. YAML Environments: Anatomy and Targets

An Environment is a logical collection of physical or virtual resources that can be targeted by deployments (e.g., development, staging, production). Environments are created under Pipelines → Environments.

Why Use YAML Environments?

1. Deployment History & Auditing: Tracks every pipeline run, commit, and work item deployed to that specific target environment over time.
2. Resource Modeling: Environments can map directly to:
   • Kubernetes: Directly links to AKS clusters and namespaces, allowing teams to visualize pod health, container images, and workload statuses directly in the Azure DevOps portal.
   • Virtual Machines: Installs the Azure Pipelines agent directly on Linux or Windows VMs, grouping them into deployment pools for rolling in-place updates.
   • Generic / PaaS: Logical endpoints representing Azure App Services, Azure Functions, or serverless infrastructure.
3. Decoupled Governance: Critical release gates (approvals, business hours, automated checks) are configured on the Environment in the portal, meaning pipeline authors cannot bypass or disable checks by modifying the YAML file in the repository.

# Targeting an Environment in a Deployment Job
- stage: DeployProd
  displayName: 'Production Deployment'
  jobs:
    - deployment: DeployApp
      displayName: 'Deploy Microservice'
      pool:
        vmImage: 'ubuntu-latest'
      environment: 'production.billing-api' # <EnvironmentName>.<ResourceName>
      strategy:
        runOnce:
          deploy:
            steps:
              - script: echo "Deploying to production billing-api workload..."

---

2. Environment Approvals and Automated Checks Matrix

Checks and approvals allow organizations to specify criteria that must be satisfied before a stage targeting an environment is permitted to execute. When a deployment job requests an environment, execution pauses, no agent compute is consumed, and the configured checks are evaluated.

Comprehensive Environment Checks Matrix

The Exclusive Lock Check: Preventing Race Conditions

In fast-moving teams with multiple developers merging pull requests, multiple pipeline runs can be triggered in rapid succession. Without concurrency control, Pipeline Run #101 (older commit) might deploy after Pipeline Run #102 (newer commit), resulting in regression.

Configuring the Exclusive Lock check on an environment guarantees sequential, serialized execution. When Run #101 enters the deployment stage, it acquires the exclusive lock on production. Run #102 will wait until Run #101 completes its deployment and releases the lock. Furthermore, Azure Pipelines provides an option to deploy only the latest queued run upon lock release, automatically canceling superseded intermediate runs.

---

3. Realistic Exam Scenarios & Common Traps

Scenario: Financial Core Banking Compliance Pipeline

Context: Contoso Bank is modernizing their core payment gateway deployment to an Azure Kubernetes Service (AKS) cluster. Banking regulations require:

1. Zero credentials stored in Azure DevOps.
2. Deployments to production must only happen from the main branch.
3. A Change Request in ServiceNow must be in the Approved state.
4. Deployments must occur between 02:00 and 05:00 UTC to minimize customer impact.
5. Only one pipeline run may deploy at any time to prevent database schema conflicts.

DevOps Solution Architecture:

• Configure an Azure Key Vault Linked Variable Group connected via an ARM Service Connection using Workload Identity Federation to securely provide database connection strings and TLS certificates.
• Define an Environment named Production-AKS.
• Configure five automated checks on the Production-AKS environment in Azure DevOps Project Settings:
  1. Branch Control: Allowed branches set to refs/heads/main.
  2. Invoke REST API: Configured with a ServiceNow service connection to poll the change ticket status until it returns status: Approved.
  3. Business Hours: Configured for 02:00–05:00 UTC daily.
  4. Exclusive Lock: Enabled to serialize all deployments.
  5. Manual Approvals: Assigned to the Core Banking CAB security group.
• In the YAML pipeline, target the environment in a deployment job: environment: 'Production-AKS'.

Common Exam Traps to Avoid

• Trap: Believing environment checks can be configured or bypassed inside YAML. Checks and approvals are managed exclusively through the Azure DevOps web portal under Pipelines → Environments → [Environment] → Approvals and checks. A developer cannot disable an approval gate or REST check by editing the YAML file in Git.
• Trap: Forgetting to map secret variables in custom scripts. Attempting to call $MY_SECRET in a bash step without defining env: MY_SECRET: $(mySecret) results in an empty variable, causing scripts to fail with authentication errors.
• Trap: Confusing Exclusive Lock on an Environment with Agent Pool concurrency. Agent pool concurrency limits how many jobs run across your pool. The Exclusive Lock on an Environment specifically serializes deployments to that target resource, regardless of how many parallel agent slots your organization has licensed.