Disable creation of classic pipelines
YAML pipelines offer the best security for your Azure Pipelines. In contrast to classic build and release pipelines, YAML pipelines:
- Can be code reviewed. YAML pipelines are no different from any other piece of code. You can prevent malicious actors from introducing malicious steps in your pipelines by enforcing the use of Pull Requests to merge changes. Branch policies make it easy for you to set this up.
- Provide resource access management. Resource owners decide if a YAML pipeline can access a resource or not. This prevents attacks like stealing another repository. Approvals and checks provide access control that works for each pipeline run.
- Support runtime parameters. Runtime parameters help you avoid a host of security issues related to variables, such as Argument Injection.
This is why many of you who are security-conscious choose to only use YAML pipelines. Alas, as long as your engineers can choose to use classic pipelines, you will have to continue worrying about their security.
We’ve launched a new feature that allows you to disable creation of classic pipelines. When you enable it, no classic build pipeline, classic release pipeline, task groups, and deployment groups can be created. Thus, there won’t be any (new) classic pipelines to worry about.
Enable the feature
You can disable creation of classic pipelines by turning on a toggle at either organization level or project level.
To turn it on at organization level, navigate to your Organization settings, then under the Pipelines section choose Settings. In the General section, toggle on Disable creation of classic build and classic release pipelines.
When you turn it on at organization level, it is on for all projects in that organization. If you leave it off, you can choose for which projects you wish to turn it on.
To turn on the toggle on at organization level, you need Project Collection Administrator rights, while for a project, you need Project Administrator rights.
How the feature works
If you turned on the toggle to Disable creation of classic build and classic release pipelines, then no classic build pipeline, classic release pipeline, task groups, and deployment groups can be created.
The user interface will not show the Releases, Task groups, and Deployment groups left-side menu items if you have none of them.
When creating a new build pipeline, you’ll no longer be able to choose Other Git or Subversion as pipeline repository.
REST APIs related to creating classic build pipeline, classic release pipeline, task groups, and deployment groups will not work anymore.
Existing classic pipelines
If you have classic build pipelines, classic release pipelines, task groups, or deployment groups, you’ll still be able to edit and run them. The Pipelines left-side menu will continue to show the corresponding menu items. However, the buttons to create new ones will be disabled.
The following screenshot shows the experience when attempting to create a new release pipeline.
Rollout
The feature is available to all customers and is turned off by default. This means there are no changes to your pipelines behavior. We do not plan to automatically turn on the feature for existing organizations.
We plan to have the feature turned on by default for organizations created after March 2023. This means new organizations will be, by default, YAML-only.
FAQ
Are classic pipelines going away?
No. Classic pipelines, both build and release, will continue to work in the future as well.
I can’t turn on Disable creation of classic build and classic release pipelines. Why?
To turn on the Disable creation of classic build and classic release pipelines toggle at organization level, you need to have Project Collection Administrators rights.
To turn on the Disable creation of classic build and classic release pipelines toggle at project level, you need to have Project Administrators rights.
Where can I learn more about securing my YAML pipelines?
Read our Securing Azure Pipelines walkthrough for recommendations to help you put together a secure YAML-based CI/CD pipeline.
28 comments
We would love to fully move to multistage yaml pipelines, but this several years outstanding issue still is a blocker for us:
https://developercommunity.visualstudio.com/t/Build-Number-Not-Updated-In-Environments/10220047
Hope you can prioritize it or at least provide some workaround.
Thanks
Hi,
Thank you for the feedback!
Classic release pipelines are not going anywhere.
We are planning to reduce the feature gap between classic release pipelines and YAML pipelines in the coming months.
Best regards,
Silviu
Hi,
Thanks for your reply, but we would really like to move to the YAML ones!
I hope a solution for this scenario will be provided soon.
Thanks 🙂
We would also love to move completely to YAML pipelines, but a massive blocker for us is the absence of a way to update the agents installed on VMs in Pipelines > Environments. (This is present for Classic Pipelines in Pipelines > Deployment Groups > {select ellipsis for a group} > Update targets.)
Dev Community issue here: https://developercommunity.visualstudio.com/t/Add-option-to-update-pipeline-environmen/1171751
Any chance of an update on why this still hasn’t been implemented an if there are any workarounds other than uninstalling and re-installing the agent? Cheers!
Hi,
Thank you for the feedback!
We are planning to reduce the feature gap between classic release pipelines and YAML pipelines in the coming months.
For your particular issue, a workaround is to navigate to Organization Settings -> Deployment pools -> Hover over the deployment pool corresponding to your Environment (its name is in the format environment-$(environmentId)-$guid -> Click the … button -> Select Update targets.
Best regards,
Silviu
Wow – huge thanks Silviu! This is a fantastic workaround. I’ve been working with TFS/VSO/VSTS/ADO for well over 10 years and never knew this existed. Cheers!
gonna ask the obvious – why isn’t the visual graph UI model used by Classic being redesigned and even ENHANCED to output pure YAML while allowing full visualisation of all manipulated Azure entities? Nothing stopping Microsoft from taking the power of a visual designer that also gives both detailed and broad overview of the entire infrastructure in context and creating code output.
Want to rapidly accelerate the development of new pipelines by removing the incredibly arduous and fiddly nature of working directly with YAML text files? – create a powerful visual graph tool.
Take a page out of the way Finite State Machines and Charts can be represented visually and in code and use that to turn Classic into a true powerhouse killer app.
Agree with the others. We don’t follow Microsoft’s approach to releases. We follow the “build once, deploy to any environment on demand” approach and the YAML pipelines for release don’t work in that scenario. Until that feature is implemented such that you can deploy to different stages at any time in the future and the release doesn’t show as “pending” or time out or whatever the existing YAML version does now then we cannot use it. We use YAML builds but YAML releases are a no-go until this is implemented.
Hi,
Thank you for the feedback!
Classic release pipelines are not going anywhere.
We are planning to reduce the feature gap between classic release pipelines and YAML pipelines in the coming months.
Best regards,
Silviu
this comment has been deleted.
This feature gap has been too big for too long. I’ll look forward to it being closed. Especially in the regard of environment deployment on demand.
This has been on the road map for three years already. https://developercommunity.visualstudio.com/t/Manually-triggered-stages-in-YAML-mult/697467?sort=votes&stateGroup=active
Hi Silviu!
I’m confused about why classic build pipelines and release pipelines are both combined into a single setting here (other settings like the pipeline token scope can be set for builds and releases separately).
Especially since build pipelines can easily be replaced with YAML, and thus it would make sense to disable them, but as long as release pipelines are still around and might never be fully replaced with YAML (as some companies just prefer visual UI-based designers).
Thanks,
–Neno
MVP, Azure DevOps
Hi Neno,
Thank you for your feedback!
Is my understanding correct that what’s holding you back from completely switching over to YAML pipelines is the UI-based editing provided by classic release pipelines?
Best regards,
Silviu
Hi Silviu!
Visual editing is one reason, but there are more. For example, the notion of defining reviewers in a pipeline vs on an environment, makes more sense for some scenarios – so the current YAML implementation isn’t really a great fit. Also the ability to trigger stages manually when needed – is very flexible in classic release pipelines.
Bottom line: YAML is great for some deployment scenarios, classic release pipelines for others. This is why I was wondering why there’s no option to disable classic builds while still keeping classic release pipelines.
Best regards,
–Neno
MVP, Azure DevOps
PS: Oh, and a big one: there’s no Pull Request policy for deployments (there is one for classic release pipelines though).
–Neno
Hi Neho,
Again, thanks so much for the feedback!
Can you please explain more that you mean by Pull Request policy for deployments?
Cheers,
Silviu
Hi Silviu,
Sure:
Does that make sense?
–Neno
I’ve tried to move completely to multi-stage yaml pipelines many times but always reverted. The are great for builds but there are far too many features missing to replace releases:
Lastly, the YAML for a multi environment pipeline is non-intuitive and too complex to review once you factor in templates and the linear way yaml is constructed.
Hi James,
Thank you for the feedback! Very informative, as are planning to reduce the feature gap between classic release pipelines and YAML pipelines in the coming months.
That said, classic release pipelines are not going anywhere.
Best regards,
Silviu
Hi Silviu,
Could you please advise the version of Azure DevOps for which disable creation of classic pipelines is available?
We’ve checked both our Azure DevOps Server versions (Azure DevOps Server 20221122.1 and Azure DevOps Server 2020 Update 1.1) and couldn’t find such toggle niether on collection nor on project levels.
The account which tried to do so has Project Collection Administrators rights.
Hi Dmitry,
The feature is currently available for Azure DevOps Services only.
Best regards,
Silviu
There are a lot of missing features in YAML pipelines.
– Post-deployment gates
– Triggers (Manual only)
Some of our teams manage Windows Services, classic release pipelines you can create a stage with a “Manual only” trigger to start/stop a service so we don’t need to grant access to the servers to those teams
Of all the missing features in YAML pipelines which ones are you actually going to implement and which ones aren’t you going to implement?
Hi, would kike to try YAML pipelines but the last time I gave a quick look my understanding is that target environments are private to each project (granted I see a benefit from a security point of view) while deployment groups can be shared.
As we deploy mutliple projects on the same target machine, my understanding is that we would need to install a separate instance of azagent for each and every project we want to deploy on this machine rather than one as we are currently doing.
Installing a service for each project deployed on a single machine is really what we should do with YAML environments ???
Great! When will you make Azure pipelines Jira integration available in YAML pipelines ? We would love to move out of classic release pipelines!
https://github.com/microsoft/azure-pipelines-jira
Hi,
We want to move all the way to YAMLs. Builds are already there.
But for releases, hadn’t found any workarouds to schedule-it or postone-it after the reviewed/authorized.
Any news on this ?
Best regards,
Leverson