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-patterns-53description: Composes Azure DevOps YAML pipelines. Templates, variable groups, multi-stage, triggers.4---5# dotnet-ado-patterns67Composable Azure DevOps YAML pipeline patterns for .NET projects: template references with `extends`, `stages`, `jobs`,8and `steps` keywords for hierarchical pipeline composition, variable groups and variable templates for centralized9configuration, pipeline decorators for organization-wide policy injection, conditional insertion with `${{ if }}` and10`${{ each }}` expressions, multi-stage pipelines (build, test, deploy), and pipeline triggers for CI, PR, and scheduled11runs.1213**Version assumptions:** Azure Pipelines YAML schema. `DotNetCoreCLI@2` task for .NET 8/9/10 builds. Template14expressions syntax v2.1516## Scope1718- Template references with extends, stages, jobs, and steps keywords19- Variable groups and variable templates for centralized configuration20- Pipeline decorators for organization-wide policy injection21- Conditional insertion with ${{ if }} and ${{ each }} expressions22- Multi-stage pipelines (build, test, deploy)23- Pipeline triggers for CI, PR, and scheduled runs2425## Out of scope2627- Starter CI templates -- see [skill:dotnet-add-ci]28- CLI release pipelines (tag-triggered build-package-release for CLI tools) -- see [skill:dotnet-cli-release-pipeline]29- ADO-unique features (environments, service connections, classic releases) -- see [skill:dotnet-ado-unique]30- Build/test specifics -- see [skill:dotnet-ado-build-test]31- Publishing pipelines -- see [skill:dotnet-ado-publish]32- GitHub Actions workflow patterns -- see [skill:dotnet-gha-patterns]3334Cross-references: [skill:dotnet-add-ci] for starter templates that these patterns extend,35[skill:dotnet-cli-release-pipeline] for CLI-specific release automation.3637---3839For detailed YAML examples (stage/job/step templates, extends, variable groups, conditional insertion, multi-stage40pipelines, triggers), see `examples.md` in this skill directory.4142## Code Navigation (Serena MCP)4344**Primary approach:** Use Serena symbol operations for efficient code navigation:45461. **Find definitions**: `serena_find_symbol` instead of text search472. **Understand structure**: `serena_get_symbols_overview` for file organization483. **Track references**: `serena_find_referencing_symbols` for impact analysis494. **Precise edits**: `serena_replace_symbol_body` for clean modifications5051**When to use Serena vs traditional tools:**5253- ✅ **Use Serena**: Navigation, refactoring, dependency analysis, precise edits54- ✅ **Use Read/Grep**: Reading full files, pattern matching, simple text operations55- ✅ **Fallback**: If Serena unavailable, traditional tools work fine5657**Example workflow:**5859```text60# Instead of:61Read: src/Services/OrderService.cs62Grep: "public void ProcessOrder"6364# Use:65serena_find_symbol: "OrderService/ProcessOrder"66serena_get_symbols_overview: "src/Services/OrderService.cs"67```6869## Agent Gotchas70711. **Template parameter types are enforced at compile time** -- passing a string where `type: boolean` is expected72 causes a validation error before the pipeline runs; always match types exactly.732. **`extends` templates cannot be overridden** -- callers cannot inject steps before or after the mandatory stages;74 this is by design for policy enforcement.753. **Variable group secrets are not available in template expressions** -- `${{ variables.mySecret }}` resolves at76 compile time when secrets are not yet available; use `$(mySecret)` runtime syntax instead.774. **`${{ each }}` iterates at compile time** -- the loop generates YAML before the pipeline runs; runtime variables78 cannot be used as the iteration source.795. **CI and PR triggers are mutually exclusive with `trigger: none` and `pr: none`** -- omitting both `trigger` and `pr`80 sections enables default CI triggering on all branches; explicitly set `trigger: none` to disable.816. **Path filters in triggers use repository root-relative paths** -- do not prefix paths with `/` or `./`; use `src/**`82 not `./src/**`.837. **Scheduled triggers always run on the default branch first** -- the `branches.include` filter applies after the84 schedule fires; the schedule itself is only evaluated from the default branch YAML.858. **Pipeline resource triggers require the source pipeline name, not the YAML file path** -- use the pipeline name as86 shown in ADO, not the `azure-pipelines.yml` file path.