Release pipelines & approvals

Promote one artifact through gated envs.

Continuous delivery is about getting changes to production safely and frequently. The release pipeline takes a built artifact and deploys it through environments with the gates and approvals that make deployment low-risk.

Environments, stages, and approvals

A continuous delivery pipeline promotes a single built artifact through a series of environments — dev, test, staging, production — deploying the same artifact at each stage so what you tested is exactly what ships. In Azure Pipelines, environments represent these deployment targets and carry approvals and checks: you gate deployment to production behind a required manual approval, and add automated checks (a query to Azure Monitor confirming no active incidents, a business-hours restriction, or a passing gate) that must succeed before the release proceeds. Multi-stage YAML pipelines express this whole build-and-deploy flow as versioned code. The result is that shipping to production is a controlled, gated, auditable process rather than an ad-hoc push.

# Multi-stage: build once, deploy the SAME artifact through environments.
stages:
  - stage: Build         # produces the artifact
  - stage: Test
    jobs: [{ deployment: deploy, environment: test }]
  - stage: Prod
    jobs:
      - deployment: deploy
        environment: production      # ← approvals + checks attach here:
          #  ✓ manual approval by release owner
          #  ✓ gate: Azure Monitor query shows no active incidents
# The artifact that passed test is the exact one promoted to prod.

Continuous delivery discipline

The goal of continuous delivery is frequent, low-risk, reversible deployments — small changes shipped often and safely, rather than rare, risky, big-bang releases. This depends on the earlier foundations: a trustworthy CI pipeline, trunk-based development, feature flags, and IaC-provisioned environments. Approvals and gates provide control without blocking flow, and every deployment is traceable back to the commits and work items it contains. When something goes wrong, automated rollback (next lesson) contains it. The DevOps engineer designs this delivery process so the team can deploy confidently and often, which research consistently links to both higher velocity and higher stability — deploying frequently in small increments is safer than deploying rarely in large ones, because each change is small and quickly reversible.