How do you use Environments, Approvals, and Checks for production deployment control?

Think of Environments in Azure DevOps like security zones in a bank building. The lobby is open to everyone, the teller area requires a badge, the vault requires a badge plus a biometric scan plus a second authorized person present. Each zone has different access controls appropriate to the sensitivity of what it protects. You do not apply vault-level security to the lobby because it would make the building unusable, but you absolutely require it before anyone accesses the vault. Azure DevOps Environments apply this same graduated security model to your deployment targets: development environments have minimal checks for fast iteration, while production environments enforce multiple governance controls.

Environments in Azure DevOps are named resources that represent the target where your application runs. Unlike Service Connections which represent authentication to external services, Environments represent the logical deployment target itself. When a deployment job references an environment, Azure DevOps creates a deployment history showing every pipeline run that deployed to that environment, including the build version, who triggered it, when it deployed, and whether it succeeded. This history provides the audit trail that compliance teams require. Environments can optionally include Kubernetes cluster registrations, virtual machine groups, or be purely logical containers for governance controls.

Manual approvals are the most common check applied to production environments. You configure one or more approvers who must explicitly approve the deployment before the pipeline continues. Approvers receive notifications through email, Teams, or the Azure DevOps mobile app. The approval UI shows what changes will be deployed, which pipeline triggered the deployment, and the build artifacts included. Approvers can defer approval, reject with comments, or approve. You can configure minimum approver count (for example, two of four designated approvers must approve), timeout periods after which pending approvals are automatically rejected, and instructions displayed to approvers explaining what to verify before approving.

Business hours checks prevent deployments outside approved windows. You configure the allowed deployment hours, days of the week, and timezone. A pipeline that reaches the production stage outside business hours pauses automatically and resumes at the start of the next valid window. This prevents 3 AM deployments that lack adequate support staff to handle failures. Combined with manual approvals, this creates a two-factor governance model: deployments can only happen during approved hours and only after a human approves.

Exclusive locks prevent multiple pipelines from deploying to the same environment simultaneously. When one deployment is in progress, any other pipeline targeting the same environment queues until the first completes. This prevents the race conditions and configuration conflicts that occur when two teams deploy to the same Kubernetes namespace simultaneously. Azure Monitor checks query a health signal after deployment and automatically roll back if the signal degrades, providing automated quality validation beyond human judgment.

The production gotcha is over-engineering checks in a way that creates deployment bottlenecks. If your production environment requires five different checks including two approvals, business hours, an exclusive lock, and an Azure Monitor check, deployments can take hours to clear all gates even for a one-line configuration change. Best practice is to layer checks proportionally: production gets full governance, staging gets automated checks only, and development gets no checks. Another issue is approval routing: if your only production approver is on vacation, deployments stall. Configure groups of approvers rather than individuals, and ensure at least three people can approve to handle coverage gaps.