L9. YAML Pipelines: Triggers, Templates & Multi-Stage Builds
CI, PR, scheduled, and pipeline-resource triggers, how stages/jobs/steps compose a multi-stage pipeline, and how YAML templates and Key Vault-linked variable groups eliminate duplication.
Pipeline Triggers
A pipeline starts when an event occurs. Azure Pipelines and GitHub Actions support multiple trigger types: CI triggers fire on pushes to specified branches or paths. You can configure "run this pipeline whenever someone pushes to main or any feature branch." PR triggers fire when a pull request is created or updated, running checks against the proposed merge. Scheduled triggers run on a cron-like schedule, useful for nightly builds, weekly security scans, or daily deployments to staging. Pipeline resource triggers (Azure DevOps) fire when another specified pipeline completes, enabling chained workflows where a build pipeline triggers a deployment pipeline.
Multi-Stage YAML Pipeline Structure
A YAML pipeline is hierarchical: stages contain jobs, which contain steps.
A stage groups related work. A build stage compiles code. A test stage runs tests. A deploy stage pushes to an environment. Stages can depend on each other and run conditionally using the dependsOn keyword. Jobs within a stage can run in parallel if they do not depend on each other.
This structure lets you express the full build-to-deploy flow in a single file:
- Stage 1: Build (runs first)
- Stage 2: Test (waits for Build to succeed)
- Stage 3: Deploy to Dev (waits for Test to succeed)
- Stage 4: Deploy to Prod (waits for Deploy to Dev, may require approval)
YAML Templates and Variable Groups
YAML templates are reusable, parameterized pipeline fragments. Instead of copying the same security scanning or build steps into every pipeline file, you define them once in a template and include them viatemplate: in each pipeline. This eliminates duplication and makes changes propagate to all pipelines automatically.
Variable groups centralize variables and secrets across multiple pipelines. A variable group can be linked to Azure Key Vault, so secret values (passwords, API keys, tokens) are stored securely and referenced by name. Without this, secrets would be duplicated across many pipeline YAML files or stored insecurely.
YAML Environments and Deployment Checks
A YAML environment represents a deployment target (dev, staging, production). An environment can have checks attached: manual approval, business hours restrictions, Azure Monitor alert checks.
When a deployment job targets an environment, it automatically inherits all checks for that environment, regardless of which pipeline YAML references it. This means approval requirements and safeguards are enforced consistently across all pipelines deploying there.
| Trigger Type | When It Fires | Use Case |
|---|---|---|
| CI trigger | On push to specified branches/paths | Run on every code change |
| PR trigger | On pull request create/update | Validate before merge |
| Scheduled | On a cron schedule | Nightly builds, weekly scans |
| Pipeline resource | When another pipeline completes | Chain build to deploy |
- ✓CI triggers fire on pushes to specified branches or paths; PR triggers fire on pull request creation or update; scheduled triggers run on a cron-like schedule; pipeline resource triggers fire when another specified pipeline completes
- ✓In a multi-stage YAML pipeline, stages contain jobs which contain steps, and a stage can use dependsOn and condition to control both ordering and whether it runs at all
- ✓YAML templates let common steps be defined once in a separate parameterized file and included via template: across many pipelines, avoiding duplication that task groups solved for classic (non-YAML) pipelines
- ✓Variable groups can be linked to Azure Key Vault, letting secret values be centrally managed and shared across multiple pipeline YAML definitions rather than duplicated as pipeline-specific secrets
- ✓A YAML environment (used in deployment jobs) represents a deployment target and can have checks like manual approval attached to it directly, so those checks apply to any pipeline that deploys to that environment
1. A team wants build, test, and deployment to three environments all expressed in one pipeline file, with each stage only running after the previous one succeeds. What YAML pipeline structure supports this?
2. Ten pipelines across different repositories all need the same three-step security scanning sequence, currently copy-pasted into every YAML file. What reduces this duplication?
3. A deployment job needs to require manual approval before deploying to production, and that same approval requirement should apply no matter which pipeline is deploying there. What is the right mechanism?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.