Design a pipeline to ensure dependency deployments are reliably ordered

When service B calls service A's new endpoint, A must be deployed and healthy first. Ordering is expressed with stage dependencies, and proven with health gates.

Order

yaml

stages:
- stage: DeployDatabase
- stage: DeployApi
  dependsOn: DeployDatabase
- stage: DeployWeb
  dependsOn: DeployApi

Remember stages are sequential by default, so this explicit chain mostly documents intent — the real work is making each stage prove success before the next begins.

Proving readiness, not just completion

A succeeded dependency satisfies the pipeline's dependency and condition model. It does not inspect whether the deployed endpoint is serving. Two mechanisms can add an explicit health signal:

postRouteTraffic in a deployment job — steps run after traffic is routed and typically monitor the updated version; make those steps fail when the health contract fails.
Resource-owner checks — configure Invoke REST API or Query Azure Monitor Alerts on a protected resource consumed by the downstream stage. The REST check continues on a successful response; the Monitor check succeeds when no configured alert rule is active.

Fan-in

yaml

- stage: DeployWeb
  dependsOn: [ DeployApi, DeployAuth ]
  condition: succeeded()

Multiple dependencies mean all must complete, and the default succeeded() means all must have succeeded.

Primary sources

Reliably ordered dependency deployments

Design a pipeline to ensure dependency deployments are reliably ordered

Order

Proving readiness, not just completion

Fan-in