Pipeline retention and classic-to-YAML migration
What it is
Pipeline retention controls how long completed runs and their artifacts, logs, symbols, and attachments remain available. Classic-to-YAML migration moves pipeline definition from portal-managed UI configuration into version-controlled YAML.
Why it exists
Keeping every run forever wastes money and can retain sensitive build output. Keeping too little makes audits, rollback, and diagnosis impossible. YAML puts reviewable pipeline logic beside the application code, but migration must preserve behavior deliberately.
Key ideas
- Set retention by project policy for Azure Pipelines; distinguish run retention from package/artifact retention requirements.
- Keep enough evidence for compliance, incident investigation, and rollback, then delete what no longer has a justified purpose.
- Exporting a Classic build pipeline can provide YAML as a starting point. Classic release pipelines require task-by-task reconstruction.
- Recreate triggers, schedules, variables, environments, approvals/checks, service connections, permissions, and retention deliberately. Do not assume an export carries them all.
- Test the YAML pipeline alongside the existing pipeline, compare outputs and deployment behavior, then retire the old route only after a controlled cutover.
Exam decision
When asked to improve traceability and code review, prefer YAML in source control. When asked to preserve historical output or meet an audit requirement, choose a justified retention policy rather than an arbitrary number of days.
Related
pipeline-yaml · build-artifact · pipeline-maintenance · pipeline-run
Sources: Pipeline retention policies · Migrate Classic pipelines to YAML