Deployment: Environments & Approvals

## The two job types Azure Pipelines YAML has two kinds of job. A regular `job:` is a unit of work that runs steps on an agent from a pool. A `deployment:` job is the same execution unit with a declared *target*: the `environment:` property. That one property is the hinge of Azure DevOps' change-control model. ## Steps move under a strategy The most visible difference is structural. A deployment job has no top-level `steps:`. Instead it has a `strategy:`, and the steps live inside one of the strategy's lifecycle hooks: ```yaml jobs: - deployment: DeployWeb environment: production pool: vmImage: ubuntu-latest strategy: runOnce: deploy: steps: - script: ./scripts/deploy.sh ``` `runOnce` is the simplest strategy: run the hooks once. `rolling` repeats them over batches of virtual-machine resources, and `canary` repeats them over percentage increments. Writing `steps:` directly under `deployment:` is a schema error, and it is the most common first mistake. ## The environment is a real object An environment is not a string label like a Git branch name. It is a project-level object with its own page under **Pipelines > Environments**. It holds: - **Deployment history** — every run that deployed to it, in order, with the commits and work items each deployment included. This is the audit trail an auditor or an incident responder asks for: *what is running in production right now, and which change put it there?* - **Resources** — optionally a Kubernetes namespace or a set of registered virtual machines, so the job can target concrete infrastructure and the page can show the live workloads or machines. - **Approvals and checks** — the gate list described below. - **Security** — which pipelines and which users may use it, including an "open access" toggle versus explicit pipeline permissions. If you reference an environment name that does not exist yet, Azure Pipelines creates it on the fly with no resources. That is convenient and also a trap: an auto-created environment has **no** checks on it, so a typo in the environment name silently produces an *ungated* deployment that goes straight through. Locking down who may create environments, and pre-creating the ones that matter, is the standard mitigation. ## Checks gate the stage When a stage contains a deployment job whose environment carries checks, the run pauses at the *start of that stage* until every check passes. No agent is consumed while it waits. The gate is attached to the environment, not written into the pipeline YAML, so a pipeline author cannot remove it by editing the file — which is exactly why compliance-minded teams like this model. ## Defaults that differ from a regular job Two defaults surprise people. A deployment job **does not check out the source repository** — add `- checkout: self` if a step needs repo files. And it **does automatically download** the pipeline artifacts published earlier in the same run, which you suppress with `- download: none`. The reasoning is that a deployment consumes an already-built artifact rather than rebuilding from source, which is the build-once-deploy-many discipline expressed as a default. ## Targeting resources When the environment holds resources, the job can name one: ```yaml environment: name: production resourceType: VirtualMachine tags: web ``` With VM resources, the machines themselves run the agent, so no `pool:` is given; the job fans out across every matching machine. With a Kubernetes resource, the resource carries the cluster service connection and namespace, so manifest tasks target it without a separate connection. ## When you do not need one Build, test and lint jobs should stay plain `job:` entries. A deployment job for work that does not change a running environment adds noise to the deployment history and buys nothing. Reach for `deployment:` exactly when the job is the thing that changes what is running somewhere.