dotnet-ado-patterns
Composable Azure DevOps YAML pipeline patterns for .NET projects: template references with extends, stages, jobs,
and steps keywords for hierarchical pipeline composition, variable groups and variable templates for centralized
configuration, pipeline decorators for organization-wide policy injection, conditional insertion with ${{ if }} and
${{ each }} expressions, multi-stage pipelines (build, test, deploy), and pipeline triggers for CI, PR, and scheduled
runs.
Version assumptions: Azure Pipelines YAML schema. DotNetCoreCLI@2 task for .NET 8/9/10 builds. Template
expressions syntax v2.
Scope
- Template references with extends, stages, jobs, and steps keywords
- Variable groups and variable templates for centralized configuration
- Pipeline decorators for organization-wide policy injection
- Conditional insertion with ${{ if }} and ${{ each }} expressions
- Multi-stage pipelines (build, test, deploy)
- Pipeline triggers for CI, PR, and scheduled runs
Out of scope
- Starter CI templates -- see [skill:dotnet-add-ci]
- CLI release pipelines (tag-triggered build-package-release for CLI tools) -- see [skill:dotnet-cli-release-pipeline]
- ADO-unique features (environments, service connections, classic releases) -- see [skill:dotnet-ado-unique]
- Build/test specifics -- see [skill:dotnet-ado-build-test]
- Publishing pipelines -- see [skill:dotnet-ado-publish]
- GitHub Actions workflow patterns -- see [skill:dotnet-gha-patterns]
Cross-references: [skill:dotnet-add-ci] for starter templates that these patterns extend,
[skill:dotnet-cli-release-pipeline] for CLI-specific release automation.
For detailed YAML examples (stage/job/step templates, extends, variable groups, conditional insertion, multi-stage
pipelines, triggers), see examples.md in this skill directory.
Code Navigation (Serena MCP)
Primary approach: Use Serena symbol operations for efficient code navigation:
- Find definitions:
serena_find_symbol instead of text search
- Understand structure:
serena_get_symbols_overview for file organization
- Track references:
serena_find_referencing_symbols for impact analysis
- Precise edits:
serena_replace_symbol_body for clean modifications
When to use Serena vs traditional tools:
- ✅ Use Serena: Navigation, refactoring, dependency analysis, precise edits
- ✅ Use Read/Grep: Reading full files, pattern matching, simple text operations
- ✅ Fallback: If Serena unavailable, traditional tools work fine
Example workflow:
# Instead of:
Read: src/Services/OrderService.cs
Grep: "public void ProcessOrder"
# Use:
serena_find_symbol: "OrderService/ProcessOrder"
serena_get_symbols_overview: "src/Services/OrderService.cs"
Agent Gotchas
- Template parameter types are enforced at compile time -- passing a string where
type: boolean is expected
causes a validation error before the pipeline runs; always match types exactly.
extends templates cannot be overridden -- callers cannot inject steps before or after the mandatory stages;
this is by design for policy enforcement.
- Variable group secrets are not available in template expressions --
${{ variables.mySecret }} resolves at
compile time when secrets are not yet available; use $(mySecret) runtime syntax instead.
${{ each }} iterates at compile time -- the loop generates YAML before the pipeline runs; runtime variables
cannot be used as the iteration source.
- CI and PR triggers are mutually exclusive with
trigger: none and pr: none -- omitting both trigger and pr
sections enables default CI triggering on all branches; explicitly set trigger: none to disable.
- Path filters in triggers use repository root-relative paths -- do not prefix paths with
/ or ./; use src/**
not ./src/**.
- Scheduled triggers always run on the default branch first -- the
branches.include filter applies after the
schedule fires; the schedule itself is only evaluated from the default branch YAML.
- Pipeline resource triggers require the source pipeline name, not the YAML file path -- use the pipeline name as
shown in ADO, not the
azure-pipelines.yml file path.
1---2name: dotnet-ado-patterns3description: Composes Azure DevOps YAML pipelines. Templates, variable groups, multi-stage, triggers.4license: MIT5---67# dotnet-ado-patterns89Composable Azure DevOps YAML pipeline patterns for .NET projects: template references with `extends`, `stages`, `jobs`,10and `steps` keywords for hierarchical pipeline composition, variable groups and variable templates for centralized11configuration, pipeline decorators for organization-wide policy injection, conditional insertion with `${{ if }}` and12`${{ each }}` expressions, multi-stage pipelines (build, test, deploy), and pipeline triggers for CI, PR, and scheduled13runs.1415**Version assumptions:** Azure Pipelines YAML schema. `DotNetCoreCLI@2` task for .NET 8/9/10 builds. Template16expressions syntax v2.1718## Scope1920- Template references with extends, stages, jobs, and steps keywords21- Variable groups and variable templates for centralized configuration22- Pipeline decorators for organization-wide policy injection23- Conditional insertion with ${{ if }} and ${{ each }} expressions24- Multi-stage pipelines (build, test, deploy)25- Pipeline triggers for CI, PR, and scheduled runs2627## Out of scope2829- Starter CI templates -- see [skill:dotnet-add-ci]30- CLI release pipelines (tag-triggered build-package-release for CLI tools) -- see [skill:dotnet-cli-release-pipeline]31- ADO-unique features (environments, service connections, classic releases) -- see [skill:dotnet-ado-unique]32- Build/test specifics -- see [skill:dotnet-ado-build-test]33- Publishing pipelines -- see [skill:dotnet-ado-publish]34- GitHub Actions workflow patterns -- see [skill:dotnet-gha-patterns]3536Cross-references: [skill:dotnet-add-ci] for starter templates that these patterns extend,37[skill:dotnet-cli-release-pipeline] for CLI-specific release automation.3839---4041For detailed YAML examples (stage/job/step templates, extends, variable groups, conditional insertion, multi-stage42pipelines, triggers), see `examples.md` in this skill directory.4344## Code Navigation (Serena MCP)4546**Primary approach:** Use Serena symbol operations for efficient code navigation:47481. **Find definitions**: `serena_find_symbol` instead of text search492. **Understand structure**: `serena_get_symbols_overview` for file organization503. **Track references**: `serena_find_referencing_symbols` for impact analysis514. **Precise edits**: `serena_replace_symbol_body` for clean modifications5253**When to use Serena vs traditional tools:**5455- ✅ **Use Serena**: Navigation, refactoring, dependency analysis, precise edits56- ✅ **Use Read/Grep**: Reading full files, pattern matching, simple text operations57- ✅ **Fallback**: If Serena unavailable, traditional tools work fine5859**Example workflow:**6061```text62# Instead of:63Read: src/Services/OrderService.cs64Grep: "public void ProcessOrder"6566# Use:67serena_find_symbol: "OrderService/ProcessOrder"68serena_get_symbols_overview: "src/Services/OrderService.cs"69```7071## Agent Gotchas72731. **Template parameter types are enforced at compile time** -- passing a string where `type: boolean` is expected74 causes a validation error before the pipeline runs; always match types exactly.752. **`extends` templates cannot be overridden** -- callers cannot inject steps before or after the mandatory stages;76 this is by design for policy enforcement.773. **Variable group secrets are not available in template expressions** -- `${{ variables.mySecret }}` resolves at78 compile time when secrets are not yet available; use `$(mySecret)` runtime syntax instead.794. **`${{ each }}` iterates at compile time** -- the loop generates YAML before the pipeline runs; runtime variables80 cannot be used as the iteration source.815. **CI and PR triggers are mutually exclusive with `trigger: none` and `pr: none`** -- omitting both `trigger` and `pr`82 sections enables default CI triggering on all branches; explicitly set `trigger: none` to disable.836. **Path filters in triggers use repository root-relative paths** -- do not prefix paths with `/` or `./`; use `src/**`84 not `./src/**`.857. **Scheduled triggers always run on the default branch first** -- the `branches.include` filter applies after the86 schedule fires; the schedule itself is only evaluated from the default branch YAML.878. **Pipeline resource triggers require the source pipeline name, not the YAML file path** -- use the pipeline name as88 shown in ADO, not the `azure-pipelines.yml` file path.