3.1.3.5. Environment Checks, Approvals, and Deployment Governance
3.1.3.5. Environment Checks, Approvals, and Deployment Governance
Agents execute the work; environment checks and approvals gate whether the work proceeds to the next stage.
| Check | Automated? | Re-evaluates on an interval? | Typical use |
|---|---|---|---|
| Approvals | No | No | Human accountability for a production release |
| Business hours | Yes | Yes — waits for the window | Change-freeze and maintenance windows |
| Azure Monitor alerts | Yes | Yes | Block while the environment is unhealthy |
| Invoke REST API / Function | Yes | Yes | Query an external change-management system |
| Exclusive lock | Yes | Yes | Serialise deployments to one environment |
| Required template | Yes | No | Force pipelines to extend an approved template |
All configured checks must pass — they combine with AND, and none can be configured to override another. The supported emergency path is a permitted user manually bypassing a check on one run, which is recorded in the audit log.
Environment checks and approvals gate deployments with both automated and human verification. Approval checks require one or more designated reviewers to sign off before deployment proceeds. Quorum-based approvals (2-of-3 must approve) satisfy four-eyes compliance requirements while remaining resilient to individual availability. Business hours checks restrict deployments to safe windows (Mon-Fri 9AM-5PM) while allowing emergency overrides through parallel approval checks. Exclusive lock checks prevent concurrent deployments to the same environment — ensuring Pipeline A completes before Pipeline B begins, avoiding mixed-state deployments. Required template checks enforce the strongest governance: the environment verifies that the pipeline YAML extends an approved template, blocking any pipeline that bypasses mandatory security scanning, testing, or approval stages regardless of who triggers it.
Content for Agent Infrastructure - see flashcards and questions for this subsection.
Environment checks compose to create sophisticated deployment governance. A production environment might combine: required template check (pipeline must extend approved YAML), minimum approval count (2-of-4 team leads), business hours restriction (Mon-Fri 9-5), and invoke REST API (custom health check endpoint).
Approvals are assigned to users or groups, and assigning a group rather than an individual is what covers absence — Azure DevOps has no delegation or alternate-approver feature, so a named individual on holiday simply blocks the pipeline. Approval history provides a complete audit trail — who approved, when, with optional justification comments. For regulated environments, this history satisfies change management audit requirements without separate change management tools.
Resource-level checks extend governance beyond environments. Azure Pipeline resources (repositories, pipelines, variable groups, service connections) can each have their own approval requirements. A service connection to production Azure subscription might require infrastructure team approval regardless of which pipeline uses it.
Template governance through required template checks is the most powerful control. Define an approved deployment template that mandates security scanning, test execution, and approval stages. Any pipeline targeting the production environment must extend this template — there's no way to bypass the required stages. This centralized governance scales across hundreds of pipelines without per-pipeline configuration.
Deployment approval timeout and escalation policies handle the "approver is on vacation" problem. Configure automatic escalation: if the primary approver doesn't respond within 4 hours, notify the backup approver. If neither responds within 24 hours, the deployment request expires. This prevents queued deployments from lingering indefinitely while maintaining the human oversight requirement. Combine with shared approval groups rather than individual approvers for resilience.
Invoke Azure Function checks enable complex validation logic that environment checks alone can't express. A pre-deployment function might query multiple monitoring systems, check change freeze schedules, verify dependent service health, and return a composite go/no-go decision. The function runs serverlessly and can incorporate business logic that varies by service, environment, and time of day.
Deployment history on environments provides a timeline of what was deployed, when, by whom, and from which pipeline run. This audit trail is invaluable during incident investigation — correlating a production error spike with a specific deployment narrows root cause analysis immediately.
Deployment concurrency control through exclusive locks prevents a common failure mode: two pipelines deploying different versions to the same environment simultaneously.
