Pipeline variables

What it is

Pipeline variables are named values a pipeline uses instead of repeating a literal in every job or script. In Azure Pipelines, user-defined variables are mutable strings. They can be defined in YAML, pipeline settings, variable groups, or during a run, then referenced with the syntax appropriate to when the value is needed.

Why it exists

Variables make one pipeline reusable across environments and runs. They suit configuration such as an artifact name, endpoint, feature flag, or deployment environment. They do not turn a pipeline into a secure configuration system by themselves; secrets and identity require separate controls.

Key ideas

• Scope and precedence are concrete. In Azure Pipelines, a job-level variable overrides the same name at stage level; stage overrides pipeline root; pipeline root overrides the Pipeline settings UI. Put a value at the narrowest scope that needs it.
• Variables differ from runtime parameters. Variables are strings and can change during a run. Runtime parameters are typed and expand while the pipeline is compiled. Choose parameters when the pipeline structure itself needs a typed input.
• Syntax determines timing. $(var) expands at runtime before a task executes; ${{ variables.var }} expands at compile time; $[variables.var] is a runtime expression commonly used for conditions. Do not use template syntax for sensitive values because it expands before runtime.
• Environment injection has rules. Non-secret user and system variables become environment variables for scripts, with names uppercased and periods changed to underscores. Secret variables are not automatically injected into a script’s environment.
• Secret variables reduce accidental display, not exposure risk. Azure Pipelines masks the full secret value in logs, but code must never echo it or rely on masking substrings. Prefer workload identity federation or a managed identity when no stored secret is needed.

Northwind example

Northwind defines environment=staging at pipeline root and overrides it with environment=production only in the protected production stage. The build task uses $(environment) at runtime. A release approver cannot accidentally change the deployment structure with that string; a typed runtime parameter would be required for compile-time structure choices. The pipeline uses federation for Azure access and keeps the remaining partner API secret in Key Vault instead of placing it in YAML.

How it fits (diagram)

Exam notes

• Azure Pipelines variables are strings; runtime parameters are typed and compile-time.
• Job → stage → root → pipeline UI is the same-name precedence order.
• $(...), ${{ ... }}, and $[...] expand at different times.

Related

pipeline-run · azure-pipelines · github-actions · advanced-yaml-pipelines

📘 Source: Microsoft Learn — Define variables