How do you use Environments, Approvals, and Checks to control production deployments in Azure DevOps?
Quick Answer
Environments represent deployment targets like staging or production. They support configurable checks including manual approvals, business hours gates, Azure Monitor alerts, REST API validations, and exclusive locks that must all pass before a pipeline stage can execute.
Detailed Answer
Think of an Environment in Azure DevOps like a secure room with multiple locks on the door. To enter (deploy), you need every lock opened: the manager must approve (manual approval), it must be during office hours (business hours check), the alarm system must show green (Azure Monitor check), and no one else can be in the room simultaneously (exclusive lock). Any single lock staying closed blocks entry entirely.
Environments are first-class resources in Azure DevOps that represent your deployment targets. Unlike Classic Release environments that existed only within a release definition, YAML environments are project-level resources with their own permissions, check configuration, and deployment history. When a deployment job references an environment, Azure DevOps evaluates all configured checks before allowing execution.
The available check types are: Manual Approval (one or more users/groups must approve with optional instructions), Business Hours (deployments only during specified windows like Mon-Fri 9am-4pm), Invoke Azure Function (call a custom function that returns pass/fail), Query Azure Monitor (check that alert rules are not firing), Invoke REST API (call any HTTP endpoint and evaluate the response), Required Template (ensure the pipeline uses an approved template), and Exclusive Lock (prevent parallel deployments to the same environment).
In production, mature teams layer multiple checks. A typical production environment has: manual approval from a tech lead (with a 4-hour timeout), business hours restriction (no Friday deployments), an Azure Monitor check verifying the staging environment is healthy, and an exclusive lock preventing two services from deploying simultaneously. The approval UI shows the deployment summary, associated work items, and code changes to help approvers make informed decisions.
The gotcha that bites teams is the interaction between checks and multi-stage pipelines. If a check fails or times out, the entire stage is marked as failed, but previous stages (like staging deployment) remain deployed. This can leave staging and production out of sync. Teams should design their pipelines to handle partial failures gracefully, either by auto-rolling-back staging or by clearly surfacing the divergence in dashboards.