In an Azure Pipelines deployment job, which lifecycle hooks can a strategy define, and when does each one run?

## One vocabulary, three cadences Azure Pipelines does something the other major CI platforms do not: it gives a deployment a *shape*. Rather than one opaque block of steps, a deployment job declares named phases, and the platform decides how many times to run them. The hooks, in execution order: 1. **`preDeploy`** — preparation. Take the target out of the load balancer, stop a service, snapshot a database, announce the deploy. 2. **`deploy`** — the change itself. Copy files, apply a manifest, run the installer. 3. **`routeTraffic`** — send live traffic to the new version. Return the machine to the load balancer, shift a Kubernetes service selector, adjust weights. 4. **`postRouteTraffic`** — the soak window. Traffic is flowing and you are watching. Smoke tests, health polling, a deliberate wait. 5. **`on: success` / `on: failure`** — exactly one of the two runs at the end. Failure is where rollback logic goes; success is where you clean up or notify. Each hook is a list of steps and can carry its own `pool:`, which is genuinely useful: you can soak from a hosted agent while deploying onto self-hosted VM resources. ## runOnce ```yaml strategy: runOnce: deploy: steps: - script: ./install.sh ``` The sequence executes once. This is the default choice and covers most deployments, including anything where the underlying platform — a Kubernetes Deployment, an App Service slot swap — is already doing the gradual part for you. ## rolling ```yaml strategy: rolling: maxParallel: 2 deploy: steps: - script: ./install.sh ``` The whole hook sequence repeats over batches of the environment's **virtual-machine** resources. `maxParallel` sets the batch size and accepts a count or a percentage such as `50%`. Rolling targets VM resources; there is no `pool:` on the job, because the registered machines are themselves the agents. Practical consequence: with `maxParallel: 2` across six machines, `preDeploy` through `postRouteTraffic` runs three times, and a failure in batch two leaves batch one on the new version and batches two and three on the old one. Your `on: failure` hook has to cope with a **mixed fleet**, which is the part people forget. ## canary ```yaml strategy: canary: increments: [10, 20] deploy: steps: - script: ./deploy.sh --percent $(strategy.increment) ``` The sequence repeats once per entry in `increments`, and the current value is exposed to steps as `$(strategy.increment)`. `increments: [10, 20]` means a pass at 10%, a pass at 20%, then the final full rollout — three iterations, not two. Canary is aimed at Kubernetes resources, where the increment is used to size a canary workload alongside the stable one. ## Where the judgment lives The hooks are mechanism, not policy. `postRouteTraffic` gives you a place to stand while traffic flows, but it does not tell you what to measure or what threshold aborts the rollout — that decision belongs to whoever owns the service's reliability targets. Two failure modes recur. A `postRouteTraffic` hook that only sleeps is theatre: it burns minutes and proves nothing, because nothing checks a signal. And an `on: failure` hook that assumes the deployment failed cleanly will make things worse when it fires halfway through a rolling batch, so write rollback steps to be idempotent and to tolerate a partially updated fleet. ## Reading it back In the run's logs the hooks appear as separate named phases per iteration, which makes a failed deploy much easier to read than a single 400-line step: you can see at a glance whether the failure was during install or after traffic arrived. That legibility is a real, underrated benefit of using the hooks rather than jamming everything into `deploy`.