3.1.3.3. Triggers, Path Filters, and Template Governance

3.1.3.3. Triggers, Path Filters, and Template Governance

Stages and jobs define what happens; triggers and templates control when and how pipelines start and what standards they must follow.

Understanding trigger types is critical for the AZ-400. CI triggers fire on commits to specified branches: trigger: branches: include: [main, release/*]. PR triggers fire when a pull request targets specified branches: pr: branches: include: [main]. PR builds validate the merge result, not just the source branch. Scheduled triggers run at specified times: schedules: - cron: '0 2 * * *' (2 AM daily). Pipeline resource triggers fire when another pipeline completes: resources: pipelines: - pipeline: build trigger: true. Path filters narrow triggers to specific directories: trigger: paths: include: [src/*] exclude: [docs/*]. Combine these to create precise automation: nightly security scans on schedule, fast CI on source changes only, and cross-pipeline orchestration for complex multi-repository deployments.

YAML Variables — Scoping and Precedence:

YAML variables in Azure Pipelines have a precedence hierarchy: (1) pipeline-level variables (defined in variables: at the top of the YAML), (2) stage-level variables (defined within a stage), (3) job-level variables, (4) variable groups (linked via variables: - group:), (5) variable templates (variables: - template: vars.yml), and (6) runtime expressions ($[...] evaluated at runtime vs ${{ }} evaluated at compile time). Queue-time variables set by the user override pipeline-level defaults. Secret variables in variable groups cannot be accessed in YAML compile-time expressions — they are only available at runtime through $(secretName) syntax.

Multi-Repository Pipelines:

Complex enterprise scenarios often span multiple repositories. Azure Pipelines supports resources: repositories: to check out additional repositories alongside the primary. This enables: consuming shared YAML templates from a central "pipeline-library" repository, building applications that depend on code in multiple repositories, and coordinating deployments across service boundaries. Each repository checkout specifies the ref (branch/tag) and path, allowing precise version pinning of shared resources.

Container Jobs:

Container jobs run pipeline steps inside a specified Docker container, guaranteeing a consistent build environment regardless of the host agent. This eliminates "works on my machine" problems and ensures exact tool version alignment. In Azure Pipelines, use container: at the job level. In GitHub Actions, use container: or run individual steps with uses: docker://.

GitHub Actions vs Azure Pipelines — Decision Framework:

When selecting between GitHub Actions and Azure Pipelines, consider these critical decision factors. GitHub Actions is workflow-first: it uses .github/workflows/ YAML files, supports a massive marketplace of community actions, and is tightly coupled with GitHub's pull request and issue ecosystem. Azure Pipelines is pipeline-first: it supports both YAML (azure-pipelines.yml) and the Classic UI editor, offers built-in environments with approval gates, and integrates natively with Azure Boards, Azure Artifacts, and Azure Key Vault through service connections.

For organizations using GitHub for source control, both platforms work — but GitHub Actions eliminates the need for a service connection between repository and pipeline. For organizations requiring Azure Boards integration, multi-stage environments with approval matrices, or deployment to on-premises infrastructure through agent pools, Azure Pipelines provides deeper native support.

YAML Pipeline Structure — Deep Dive:

A well-structured YAML pipeline in Azure Pipelines follows a hierarchy: Trigger → Pool → Stages → Jobs → Steps. Each stage represents a logical phase (Build, Test, Deploy_Staging, Deploy_Production). Each job runs on an agent. Each step is a task or script. Path filters on triggers ensure that documentation-only changes don't trigger a full build pipeline. Variable groups linked to Azure Key Vault centralize secret management across stages.

Pipeline Templates — Reuse Patterns:

Templates are the cornerstone of scalable pipeline architecture. There are four template types: stage templates, job templates, step templates, and variable templates. A stage template encapsulates an entire deployment flow. A step template encapsulates reusable build or test logic. Templates can live in the same repository or in a shared template repository referenced via resources: repositories:. Organizations should maintain a central "pipeline cookbook" repository of approved templates that enforce security scanning, artifact publishing, and deployment patterns consistently across all teams.

Self-Hosted Agents — When and Why:

Self-hosted agents are necessary when: (1) builds require licensed software not available on Microsoft-hosted agents, (2) the pipeline needs network access to on-premises resources behind a firewall, (3) build times are too long on Microsoft-hosted agents due to cache invalidation (since each run gets a fresh VM), or (4) compliance requirements mandate that source code and artifacts never leave your network. The trade-off is operational overhead — you must maintain the agent OS, runtime dependencies, and security patches. Use Azure Virtual Machine Scale Sets (VMSS) agent pools for auto-scaling self-hosted agents that balance cost and availability.

Checks and Approvals — Environment Gates:

YAML-based environments in Azure Pipelines support multiple check types beyond manual approval: business hours restrictions (limit deployments to working hours), exclusive lock (prevent concurrent deployments to the same environment), required template (enforce that only approved pipeline templates can deploy), invoke Azure Function (run custom validation logic), and query Azure Monitor (verify health metrics before proceeding). These checks compose to create a defense-in-depth approval chain for production deployments.

Reflection Question: How does designing and implementing a pipeline (using Azure Pipelines, YAML, self-hosted agents, reusable templates, and checks/approvals) fundamentally ensure efficient, reliable, and automated software delivery by codifying the entire process and providing critical quality gates?