Design and implement build and release pipelines
Pipeline Health, Cost, and Migration
CoreMeasure pipeline reliability and duration, optimize the proven bottleneck, control concurrency and retention, and migrate classic behavior incrementally to YAML.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Optimization without a baseline trades one constraint for another. Faster pipelines can cost more, lose evidence, introduce shared-state races, or silently change release governance.
Must Know
- Track pass rate, failure rate, duration, task duration, queue time, agent utilization, and flaky tests by branch, pipeline, task, and agent.
- Use caching for reproducible dependencies keyed by lock data; use artifacts for outputs that later jobs or releases must consume.
- Parallel jobs require both an executable dependency graph and sufficient parallel-job and agent capacity.
- Partition tests only when slices are independent; shared singleton tools or mutable self-hosted workspaces can create races.
- Use concurrency groups, environment locks, or exclusive checks when two deployments would conflict.
- Retention should distinguish disposable pull-request outputs, release evidence, packages still consumed in production, and legal or audit requirements.
- Classic-to-YAML migration begins with an inventory of triggers, variables, tasks, identities, artifacts, approvals, and observed output before incremental comparison.
Compare and Distinguish
- Cache accelerates reconstruction; artifact transfers an output; package supplies a versioned dependency.
- More agents do not overcome an exhausted parallel-job entitlement; more entitlement does not fix missing compatible agents.
- YAML defines orchestration; resource checks preserve governance outside the file.
Scenario examples
- Scenario: Builds queue although agents are idle. Think: check parallel-job capacity and agent demands before adding machines.
- Scenario: Classic release approvals disappear during migration. Think: recreate them as environment or protected-resource checks.
Exam traps
- Caching mutable outputs can produce a fast but unreproducible build.
- Retaining every run indefinitely increases cost without preserving the right release evidence.
- A big-bang migration makes behavioral drift hard to isolate.
Key takeaways
- Measure queue, execution, failure, and flakiness separately.
- Parallelize independent work and serialize conflicting deployments.
- Migrate behavior and governance, not only visible tasks.
How it works
- Pipeline analytics correlate duration and outcome with tasks, agents, branches, and tests so the actual constraint can be isolated.
- Retention policies evaluate eligible runs, artifacts, and package versions while explicit protection preserves release evidence.
Objects and administrative surfaces
- Azure Pipelines Analytics, test failure reports, agent pools, parallel jobs, caching, artifacts, retention, environments, and migration tooling.
- GitHub Actions usage, run history, caching, artifacts, concurrency, runner groups, and retention.
When to use it
- Use a scoped concurrency lock when deployments conflict on one environment but build and test work remains independent.
Security and governance implications
- Retain audit evidence for releases, keep migration service connections scoped, and avoid shared mutable workspaces for untrusted jobs.
Troubleshooting signals
- Compare the last known-good run by task version, agent image, cache key, queue time, and test history before buying capacity.
More detail
- Key dependency caches to reproducible inputs and use artifacts for outputs that later jobs or releases must consume.
- Set retention by evidence and consumer lifecycle, protecting promoted packages and production release artifacts from generic cleanup.
- Migrate classic pipelines by inventorying triggers, tasks, resources, approvals, artifacts, and behavior before incremental YAML comparison.
Ready for the quiz?
- What limits Azure Pipelines job concurrency?
- When is a cache inappropriate?
- Which classic controls must move outside YAML?
Related objectives
- D3.6.S1 — Monitor pipeline health, including failure rate, duration, and flaky tests
- D3.6.S2 — Optimize a pipeline for cost, time, performance, and reliability
- D3.6.S3 — Optimize pipeline concurrency for performance and cost
- D3.6.S4 — Design and implement a retention strategy for pipeline artifacts and dependencies
- D3.6.S5 — Migrate a pipeline from classic to YAML in Azure Pipelines