Azure DevOps – Pipeline Variables and Variable Groups
1. What are Pipeline Variables?
Pipeline Variables are key-value pairs used to store configuration values in Azure DevOps Pipelines.
Instead of hardcoding values directly into YAML, we define variables and reuse them throughout the pipeline.
Example
Suppose you are deploying an ASP.NET Core Web API application.
You need these values:
-
Application name:
EmployeeAPI -
Build configuration:
Release -
Environment:
SIT -
Deployment path:
C:\Deploy\EmployeeAPI
Instead of repeating these values in multiple places, you can define them as variables.
variables:
appName: 'EmployeeAPI'
buildConfiguration: 'Release'
environmentName: 'SIT'
deployPath: 'C:\Deploy\EmployeeAPI'
You can access them using:
$(appName)
$(buildConfiguration)
$(environmentName)
$(deployPath)
Main purpose: Make pipelines reusable, maintainable, and easier to configure across different environments.
2. Why do we need Pipeline Variables?
Consider an ASP.NET Core application deployed to three environments.
|
Configuration |
DEV |
SIT |
PROD |
|---|---|---|---|
|
Environment |
Development |
SIT |
Production |
|
Build configuration |
Debug |
Release |
Release |
|
API URL |
dev-api.example.com |
sit-api.example.com |
api.example.com |
|
Database |
Employee_Dev |
Employee_SIT |
Employee_Prod |
Without variables, you may need to modify hardcoded values whenever you deploy to another environment.
With variables, the pipeline logic remains the same while configuration values change.
Advantages
-
Reusability: Use the same YAML pipeline for multiple environments.
-
Maintainability: Change a value in one place.
-
Security: Store sensitive values as secret variables.
-
Flexibility: Override values at the appropriate scope.
-
Centralized configuration: Share common settings using Variable Groups.
3. How do Pipeline Variables work?
Developer pushes code
|
v
Azure DevOps Pipeline starts
|
v
Load Pipeline Variables
|
v
appName = EmployeeAPI
buildConfiguration = Release
|
v
Execute Build Tasks
|
v
dotnet build --configuration Release
|
v
Publish Build Artifact
|
v
Deploy Application
YAML Example – ASP.NET Core Build
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
projectPath: 'src/EmployeeAPI/EmployeeAPI.csproj'
steps:
- script: dotnet restore $(projectPath)
displayName: 'Restore Packages'
- script: dotnet build $(projectPath) --configuration $(buildConfiguration)
displayName: 'Build Application'
- script: dotnet publish $(projectPath) --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)
displayName: 'Publish Application'
Here:
-
buildConfigurationis a custom variable. -
projectPathis a custom variable. -
Build.ArtifactStagingDirectoryis a predefined Azure DevOps variable.
When the pipeline executes, Azure DevOps substitutes the variable values.
4. Types of Pipeline Variables
Azure DevOps supports several variable categories and scopes.
|
Type |
Description |
|---|---|
|
User-defined |
Variables created by developers |
|
Predefined |
Built-in variables provided by Azure DevOps |
|
Secret |
Sensitive values such as passwords and tokens |
|
Output |
Values produced by one step/job and consumed later |
|
Variable Group |
Shared collection of variables |
A. User-defined variables
variables:
appName: 'EmployeeAPI'
buildConfiguration: 'Release'
Usage:
- script: echo $(appName)
B. Predefined variables
Azure DevOps automatically provides variables such as:
|
Variable |
Purpose |
|---|---|
|
|
Unique build ID |
|
|
Build number |
|
|
Source branch name |
|
|
Source code directory |
|
|
Directory for preparing artifacts |
Example:
steps:
- script: |
echo $(Build.BuildId)
echo $(Build.SourceBranchName)
C. Secret variables
Secret variables store sensitive values such as:
-
Database passwords
-
API keys
-
Access tokens
-
Connection strings containing credentials
Secret variables should be configured through the pipeline UI or a Variable Group, rather than hardcoded in YAML.
For example, a secret named dbPassword can be mapped to an environment variable:
steps:
- script: dotnet run
env:
DB_PASSWORD: $(dbPassword)
Azure DevOps masks registered secret values in logs where possible, but masking is not a complete security guarantee. Avoid printing secrets.
5. What are Variable Groups?
A Variable Group is a centralized collection of variables that can be shared across multiple Azure DevOps pipelines.
It is managed under:
Azure DevOps → Pipelines → Library → Variable groups
Example
Suppose your organization has three ASP.NET Core applications:
-
EmployeeAPI
-
PayrollAPI
-
AttendanceAPI
All three applications use the same SIT environment settings.
Instead of defining identical variables separately in three pipelines, create one Variable Group.
Variable Group: SIT-Configuration
|
Variable |
Value |
|---|---|
|
|
SIT |
|
|
https://sit-api.example.com |
|
|
Employee_SIT |
|
|
Release |
|
|
Secret (masked) |
All three pipelines can reference this group, subject to pipeline authorization.
How Variable Groups work
Azure DevOps Library
|
v
Variable Group: SIT-Configuration
|
+-------------------+
| |
v v
EmployeeAPI Pipeline PayrollAPI Pipeline
|
v
AttendanceAPI Pipeline
All use shared SIT configuration
Important: Updating a shared variable can affect every pipeline that consumes it on subsequent runs.
6. How to create a Variable Group in Azure DevOps
Step 1 – Open Variable Groups
Navigate to:
Azure DevOps
|
+-- Project
|
+-- Pipelines
|
+-- Library
|
+-- Variable groups
Step 2 – Create a group
Click + Variable group.
Enter the name:
SIT-Configuration
Step 3 – Add variables
|
Name |
Value |
|---|---|
|
|
SIT |
|
|
https://sit-api.example.com |
|
|
Release |
|
|
Enter password and select the lock icon |
Click Save.
Step 4 – Use the Variable Group in YAML
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
- group: SIT-Configuration
steps:
- script: |
echo "Environment: $(environmentName)"
echo "API URL: $(apiBaseUrl)"
echo "Configuration: $(buildConfiguration)"
The pipeline loads the variables from SIT-Configuration.
The group must be authorized for use by the pipeline. You can manage this through the group's pipeline permissions.
7. Using Variable Groups for DEV, SIT, UAT and Production
This is a common real-world interview scenario.
Create separate Variable Groups:
DEV-Configuration
SIT-Configuration
UAT-Configuration
PROD-Configuration
Each group contains environment-specific settings.
|
Variable |
DEV |
SIT |
PROD |
|---|---|---|---|
|
|
DEV |
SIT |
PROD |
|
|
dev-api.example.com |
sit-api.example.com |
api.example.com |
|
|
Employee_DEV |
Employee_SIT |
Employee_PROD |
Example – Multi-stage deployment
stages:
- stage: Deploy_SIT
variables:
- group: SIT-Configuration
jobs:
- job: SIT
steps:
- script: |
echo "Deploying to $(environmentName)"
echo "API URL: $(apiBaseUrl)"
- stage: Deploy_PROD
variables:
- group: PROD-Configuration
jobs:
- job: PROD
steps:
- script: |
echo "Deploying to $(environmentName)"
echo "API URL: $(apiBaseUrl)"
This example demonstrates variable selection; it does not actually deploy the application.
In a real pipeline, use deployment jobs, environment approvals, and deployment tasks. You can deploy the same build artifact to different environments while applying the appropriate configuration.
8. Pipeline Variables vs Variable Groups
|
Feature |
Pipeline Variables |
Variable Groups |
|---|---|---|
|
Purpose |
Store pipeline configuration |
Share configuration across pipelines |
|
Scope |
Pipeline, stage, or job |
Shared library, referenced by pipelines |
|
Defined in |
YAML or Pipeline UI |
Pipelines Library |
|
Reusability |
Primarily within a pipeline |
Across multiple pipelines |
|
Secret support |
Yes |
Yes |
|
Azure Key Vault integration |
Not directly through ordinary variables |
Supported |
|
Best use |
Build settings, paths |
Shared environment configuration |
Simple example:
Pipeline Variable:
variables:
buildConfiguration: 'Release'
Variable Group:
variables:
- group: PROD-Configuration
Both are accessed using the same macro syntax:
$(variableName)
9. Variable Syntax – Important for Interviews
Azure Pipelines has three commonly used variable expression syntaxes.
|
Syntax |
Evaluation |
Common use |
|---|---|---|
|
|
Before a task executes |
Normal variable usage |
|
|
Template compilation |
Templates and compile-time logic |
|
|
Runtime expression evaluation |
Conditions and calculated values |
Example:
variables:
appName: 'EmployeeAPI'
isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
steps:
- script: echo $(appName)
- script: echo ${{ variables.appName }}
- script: echo $(isMain)
Note that Azure Pipelines also supports environment variables inside scripts, such as $APPNAME in Bash or $env:APPNAME in PowerShell.
Variable scope and precedence
Variables can be defined at different levels.
Pipeline-level variable
|
v
Stage-level variable
|
v
Job-level variable
When the same variable name is defined at multiple YAML scopes, the more local definition takes precedence.
10. Variable Groups vs Azure Key Vault
Variable Groups can integrate with Azure Key Vault to retrieve secrets securely.
Azure Key Vault
|
| Stores secrets
v
Key Vault-linked Variable Group
|
v
Azure DevOps Pipeline
|
v
Deploy ASP.NET Core Application
Example:
variables:
- group: Production-Secrets
Here, Production-Secrets is assumed to be a Variable Group linked to Azure Key Vault.
Azure DevOps retrieves the mapped secret values at runtime using the configured Azure service connection.
Why use Key Vault?
-
Centralized secret management
-
Better control over secret access
-
No need to hardcode passwords
-
Easier secret rotation
Key Vault-linked Variable Groups map secret names to Key Vault secrets; they do not automatically synchronize every type of Key Vault object.
11. Advantages and Disadvantages
|
Advantages |
Disadvantages / Considerations |
|---|---|
|
Reduces hardcoding |
Incorrect values can break deployments |
|
Improves reusability |
Shared changes can impact multiple pipelines |
|
Supports multiple environments |
Variable naming must be consistent |
|
Supports secrets |
Secrets still require secure handling |
|
Integrates with Azure Key Vault |
Permissions and service connections require setup |
12. Important Interview Questions and Answers
Q1. What is a Pipeline Variable?
A Pipeline Variable is a key-value pair used to store reusable configuration values in Azure DevOps Pipelines.
Q2. What is a Variable Group?
A Variable Group is a centralized collection of variables that can be shared across multiple pipelines.
Q3. What is the main difference between Pipeline Variables and Variable Groups?
Pipeline Variables are generally used for pipeline-specific configuration, whereas Variable Groups are used to centrally manage and share configuration across pipelines.
Q4. Can Variable Groups store passwords?
Yes. They support secret variables and can also integrate with Azure Key Vault.
Q5. How do you access a Variable Group in YAML?
variables:
- group: SIT-Configuration
Access a variable using:
$(environmentName)
Q6. How do you manage variables across DEV, SIT, UAT and PROD?
Create separate Variable Groups for each environment and reference the appropriate group in each deployment stage.
Q7. Can one Variable Group be used by multiple pipelines?
Yes, provided those pipelines are authorized to access it.
Q8. What is the difference between variables and parameters?
Variables are primarily used for runtime configuration and can be updated during execution. Parameters are evaluated during template parsing and are useful for controlling pipeline structure and selecting configuration before execution.
Q9. How do you update a variable during pipeline execution?
Use a logging command:
steps:
- bash: |
echo "##vso[task.setvariable variable=appVersion]1.0.5"
- bash: |
echo "Version: $(appVersion)"
The variable is available to subsequent steps in the same job. Sharing values across jobs or stages requires output-variable configuration.
13. Real-time Interview Scenario
Question: You have three ASP.NET Core Web API applications deployed to DEV, SIT, UAT and PROD. How would you manage their configuration in Azure DevOps?
Answer:
"I would use Pipeline Variables for application-specific build settings such as project path and build configuration.
For environment-specific settings, I would create separate Variable Groups for DEV, SIT, UAT and Production.
Each deployment stage would reference the appropriate Variable Group. I would store sensitive information in Azure Key Vault and access it through Key Vault-linked Variable Groups.
This allows us to reuse the same build artifact across environments without hardcoding configuration values. Production deployment would additionally require environment approval."
Key points to remember
-
Pipeline Variables: Store reusable configuration values.
-
Variable Groups: Share configuration across multiple pipelines.
-
Secret Variables: Protect sensitive values.
-
Azure Key Vault: Centrally manage secrets.
-
Environment-specific Groups: Keep DEV, SIT, UAT and PROD configurations separate.
-
YAML Reference:
variables: - group: GroupName(written on separate YAML lines). -
Variable Usage:
$(variableName).
For an Azure DevOps interview, the most important concepts are Pipeline Variables vs Variable Groups, secret handling, environment-specific configuration, and Azure Key Vault integration.