Environments and Approvals: Protect the Destination
Put deployment checks on protected resources, verify who can approve or bypass, and connect an approved run to an actual environment.
Protect the loading dock, not just the delivery note
If a driver can rewrite the delivery note to remove the required inspection, the inspection is not independent. Deployment controls work best when owners of the protected environment or service connection manage them separately from ordinary pipeline edits.
An environment provides a named deployment target and history. It can participate in approvals and protection rules, but merely naming a job production does not create those protections.
Azure Pipelines: YAML uses a protected resource
A deployment job references an environment:
jobs:
- deployment: DeploySandbox
pool:
vmImage: ubuntu-latest
environment: learning-sandbox
strategy:
runOnce:
deploy:
steps:
- script: echo "Approval-flow exercise; no application deployed"This is a harmless approval-flow exercise. A real deployment would download the exact tested artifact and run the reviewed target-specific command.
Configure the environment and its checks in Azure DevOps. Azure approvals and checks are managed on protected resources, not simply declared as a magical approval: true field in the pipeline YAML. The resource owner can attach approval, branch-control, business-hours, or other supported checks.
Review:
| Control | Question |
|---|---|
| Environment permissions | Who may use or administer this target? |
| Pipeline authorization | Which pipelines may consume it? |
| Approvers | Who may approve, and may they approve their own run? |
| Timeout/rejection | What happens when nobody approves or someone rejects? |
| Bypass | Who can override checks, and what is audited? |
| Concurrency | Can two releases race against the same target? |
Checks on a service connection, agent pool, or other protected resource may apply alongside environment checks. Inspect the complete resource path, not one settings panel.
Approval is a decision, not a delay
Give approvers the commit, exact artifact identity, test evidence, deployment plan, risks, and rollback route. “Approve build 500” is weak if the approver cannot tell what changed or whether production will actually use its artifact.
Define what the approver is deciding. Business readiness, separation of duties, and a technical health check are different purposes. A human waiting period is a poor replacement for a deterministic check that a machine can perform reliably.
After approval, verify the deployment and runtime health. Approval is permission to attempt the change; it is not evidence that the change succeeded.
GitHub: reference the environment explicitly
A job can consume a preconfigured GitHub environment:
name: Sandbox approval exercise
on:
workflow_dispatch:
permissions:
contents: read
jobs:
approval-check:
runs-on: ubuntu-latest
environment: learning-sandbox
steps:
- run: echo "Environment gate passed; no deployment performed"Configure supported required reviewers, prevention of self-review, branch/tag restrictions, and other protection rules in the environment settings. Availability depends on repository visibility and GitHub plan; verify the current documentation rather than promising every private repository has every control.
Environment secrets are available only after applicable protection rules are satisfied. This is different from repository secrets, which have a different scope. Keep deployment credentials at the narrowest appropriate boundary and avoid exposing them to a preliminary untrusted build job.
GitHub environment required reviewers do not mean every listed reviewer must approve. Understand the documented approval semantics before treating a list as a multi-person quorum.
Prevent overlapping releases
Two individually valid releases can still conflict. Use a target-appropriate exclusive lock or concurrency design and decide whether an older waiting deployment should continue, queue, or be canceled.
Cancellation is not rollback. If a deployment already changed a database or shifted traffic, stopping the job may leave partial state. Design deployment steps to detect state and recover safely.
An agent can collect approval evidence or draft a rollout summary. It should not approve its own change or expand its permissions to impersonate an approver. Keep the decision visible and attributable.
A developer can edit Azure pipeline YAML. Where should an independent production approval be configured?
Try it: observe a waiting deployment
Prerequisites: a sandbox environment where your plan and permissions support an approval rule, plus an eligible separate approver if testing separation. CI use may be billed.
Create the harmless job above, configure one approval rule, and trigger it. Inspect the waiting state, approver identity, timeout, and resource authorization. Reject one run and approve another. Confirm the echo step runs only in the permitted case.
Expected observation: a recorded approval/rejection controls the target-consuming job. No application deployment has occurred in this exercise.
Cleanup: remove the sandbox approval and environment only if you created them and no other pipeline uses them. Do not remove shared production checks.
Decision check: the gate is missing from one release path
Inspect alternate pipelines, service connections, direct credentials, and bypass roles. A protected happy path is incomplete if another authorized route can silently skip it.