4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Maintain pipelines
Glenmoor Pharma's regulators require that every pipeline run that deploys to production, including its logs, test results, and artifacts, must be kept for 2 years. Non-production runs of the same YAML pipeline should follow the project's default 30-day retention to control storage. The process must not rely on anyone remembering to mark runs manually.
What should you implement?
- AIncrease the project retention setting for days to keep runs to the maximum for all pipelinesRaising the project setting keeps every run of every pipeline longer, inflating storage for non-production runs, and it is not targeted at production deployments.
- BAdd a step to the production stage that calls the Retention Leases REST API with $(System.AccessToken) to create a lease for the current run with daysValid: 730A retention lease created automatically in the production stage keeps that specific run and its artifacts for two years, while other runs still follow the default policy.
- CSet the retention policy on the Azure Artifacts feed to keep 730 versions of each packageFeed retention applies to packages in Azure Artifacts, not to pipeline runs, logs, or test results.
- DHave the release manager select Retain on each production runManually retaining runs depends on a person remembering, which the scenario rules out.
Why: Azure Pipelines deletes runs according to project-level retention settings unless something holds them. Retention leases are that hold: each lease keeps a specific run for a set number of days, and pipelines can create them automatically through the REST API using the job access token. Creating the lease only in the production stage targets exactly the runs that regulators care about, leaving other runs on the cheaper default. Manual retention and broad project settings either fail the automation requirement or waste storage.
Maintain pipelines
Ashford Councils has a classic build pipeline named HR-Build that uses a task group called DotNetBuildAndTest, and a classic release pipeline that deploys to three stages with pre-deployment approvals. The team must move both to YAML stored in the repository, preserve the approvals, and minimize rework.
Which migration approach should you use?
- AUse Export to YAML on HR-Build, convert the DotNetBuildAndTest task group into a steps template, and recreate the release as YAML stages with deployment jobs targeting environments that have approval checksExport to YAML produces a starting YAML file for the classic build, task groups map to step templates, and release stages with approvals map to deployment jobs and environment checks, which must be written by hand.
- BUse Export to YAML on the classic release pipeline to generate multi-stage YAML with approvalsClassic release pipelines have no export to YAML; the stages, approvals, and gates must be recreated with environments and checks.
- CReference the DotNetBuildAndTest task group directly from the YAML file with a task: entryYAML pipelines cannot consume classic task groups; the equivalent reusable element is a YAML template.
- DKeep approvals as a ManualValidation task at the start of each YAML deployment jobManualValidation runs only in agentless jobs and does not provide the reusable, environment-level approval that classic pre-deployment approvals offered.
Why: Migrating from classic pipelines to YAML maps each classic concept to its YAML equivalent. Classic build pipelines can be exported to YAML as a starting point, though variables and triggers should be reviewed afterward. Task groups become step or job templates, and classic release stages become YAML stages whose deployment jobs target environments, where approvals and checks now live. Because releases cannot be exported, that part of the migration is rewritten by hand.
Maintain pipelines
Ravenhill Software publishes a prerelease NuGet package on every CI run to an Azure Artifacts feed named core-libs, and the feed has grown to 40,000 versions, increasing its storage bill. Older versions are rarely used, but any version that a build downloaded recently must stay available. The team wants storage to be cleaned up automatically.
What should you configure?
- AFeed retention policies on core-libs: a maximum number of versions per package and a number of days to keep recently downloaded packagesFeed retention deletes the oldest versions above the limit while keeping any version downloaded within the configured number of days.
- BA pipeline retention policy that keeps runs for 10 daysPipeline retention removes runs and their pipeline artifacts, not packages stored in an Azure Artifacts feed.
- CAn upstream source from nuget.org on core-libsUpstream sources add packages from public registries; they do not delete old internal versions.
- DPromote every package to the @Release viewViews control which versions consumers see but do not reduce storage, and packages in views are protected from deletion by retention.
Why: Pipeline runs and package feeds have separate retention settings. Azure Artifacts feed retention policies cap the number of versions kept per package and keep recently downloaded versions for a set number of days, so the policy removes stale prerelease builds without breaking active consumers. Versions promoted to a view are exempt, which is why views should hold only meaningful releases. Pipeline retention never touches feed contents.
Maintain pipelines
Sandpiper Robotics has a private Azure DevOps project with 25 developers on Basic access. It uses only the free grant of Microsoft-hosted agents, and pull request builds often wait 30 minutes in the queue behind each other. The company has spare Windows servers on premises with the required build tools and wants to run up to four builds at once while minimizing cost. None of the developers have Visual Studio subscriptions.
What should you do?
- ABuy three additional Microsoft-hosted parallel jobsMicrosoft-hosted parallel jobs cost more than self-hosted ones, and the company already has suitable servers.
- BInstall agents on four on-premises servers and buy three self-hosted parallel jobs to add to the one free self-hosted parallel jobPrivate projects include one free self-hosted parallel job; buying three more allows four concurrent builds on existing hardware at the lowest cost.
- CInstall agents on four on-premises servers; no purchase is needed because self-hosted agents are unlimitedYou can register any number of self-hosted agents, but the number running jobs at once is limited by self-hosted parallel jobs, so only one would run without a purchase.
- DSplit the pipeline into four jobs in one stageSplitting jobs does not increase concurrency; extra jobs wait for the same single parallel job.
Why: Concurrency in Azure Pipelines is governed by parallel jobs, which are purchased separately for Microsoft-hosted and self-hosted agents. A private project gets one free Microsoft-hosted parallel job with a monthly minute limit and one free self-hosted parallel job with unlimited minutes. Each Visual Studio Enterprise subscriber adds another self-hosted parallel job, but that does not apply here. Using existing servers with purchased self-hosted parallel jobs is the cheapest way to reach four concurrent builds.