Reusable Pipeline Elements, Checks and Approvals

What it is

Copying the same steps into fifty pipelines means fifty places to fix. Reusable elements put the shared logic in one place. Checks and approvals put control over sensitive resources in one place too, outside the pipeline file, so authors cannot remove them.

How it works

YAML templates

A template is a YAML file included from another file. Templates can define steps, jobs, stages or variables, and accept parameters.

# templates/build-steps.yml
parameters:
- name: configuration
  type: string
  default: Release
steps:
- script: dotnet build -c ${{ parameters.configuration }}

# azure-pipelines.yml
steps:
- template: templates/build-steps.yml
  parameters:
    configuration: Debug

Template expressions ${{ }} are evaluated at compile time. Macro syntax $(var) is replaced at runtime before a task runs. Runtime expressions $[ ] are evaluated at runtime and used in conditions and some mappings.

Variables and variable groups

Secrets are never exposed to a script automatically. You map them explicitly, for example env: MY_SECRET: $(mySecret).

Task groups and GitHub reuse

Task groups bundle a sequence of tasks into one reusable task in the classic editor. In YAML, use templates instead.

Environments

An environment is a named target such as staging or production. A deployment job points at it with environment:. Environments record deployment history, can include resources (Kubernetes namespaces, virtual machines), and are where approvals and checks usually live. GitHub has the same concept with environments, secrets and protection rules.

Approvals and checks

Checks are set on protected resources by the resource owner, not in the YAML: environments, service connections, repositories, variable groups, secure files and agent pools can all have checks. Before a stage that uses the resource runs, all checks must pass.

Evaluation order: static checks (branch control, required template, evaluate artifact), pre-check approvals, dynamic checks (approval, Azure Function, REST API, business hours, Azure Monitor alerts), post-check approvals, then the exclusive lock. An approver may also defer approval to a later time. Administrators of the resource can bypass some checks for a hotfix, and the bypass is logged.

A worked scenario

A security team needs every production deployment to run a mandatory scan. They create a secure-deploy.yml template with the scan and deploy steps, then add a Required template check to the production service connection, so any pipeline using it must extend that template. They add an approval by the release managers group and a branch control check for refs/heads/main. Pipeline authors can still use their own build steps but cannot remove the controls.