Did you notice DevBlogs has a new UI and awesome new features?

January 24th, 2023

Disable creation of classic pipelines

Silviu

Senior Product Manager

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.

Author

Silviu

Senior Product Manager

28 comments

Discussion is closed. Login to edit/delete existing comments.

Sort by :

Newest

Newest Popular Oldest

Workman, Joseph March 6, 2023 0

Is there is roadmap for classic features being migrated to the new system?
Andrew Stanton February 19, 2023 0

YAML pipelines offer the best security for your Azure Pipelines

Sorry they do not. Consider an org that has to keep pipelines between each repo consistent. Sticking the build definition in the repo not only creates churn in the same way bumping version numbers does but it also means that any of the committers can alter the pipeline. This can be anywhere from desirable when the committers are skilled in this area...
Read more

YAML pipelines offer the best security for your Azure Pipelines

Sorry they do not. Consider an org that has to keep pipelines between each repo consistent. Sticking the build definition in the repo not only creates churn in the same way bumping version numbers does but it also means that any of the committers can alter the pipeline. This can be anywhere from desirable when the committers are skilled in this area (rare IME) to disastrous like when they are getting inconsistent results for unit tests and rather than fix the code they turn off the unit tests. Or when some step is taking too long so they disable it and cause bigger problems later.

You can say its different from “Classic Pipelines” but you cannot say that it is more secure when its easier to negatively affect the team’s output. Classic Pipelines can use membership in the Build Administrators group or other ways to prevent tampering. I dont even think you can say YAML pipelines are “better” than “Classic” when they havent reached feature parity.

Whomever started calling them “Classic” was clearly not around for the two generations of Windows Workflow Foundation style builds that preceded them, or the tfsbuild.proj style builds that preceded the WWF ones. None of those were easy to maintain or to work with. The thing you call “classic” and are so eager to throw in the fire along with so many other great inventions is still the easiest to learn and use – and it keeps build and packaging concerns out of the program code repo.

Read less
Justin Holbrook February 13, 2023 0

Thank you. The option to disable use of TFVC repos and remove existing repos would be welcome as well.
Leverson Carlos February 10, 2023 0

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
Mohamed Basher February 10, 2023 0

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
Patrice Scribe February 9, 2023 0

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...
Read more
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 ???

Read less
OSBORNE Luke February 8, 2023 · Edited 0

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...
Read more
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?

Read less
Dmitry Repin January 31, 2023 0

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.
- Silviu Author February 8, 2023 0
  
  Hi Dmitry,
  
  The feature is currently available for Azure DevOps Services only.
  
  Best regards,
  Silviu
James Snape January 26, 2023 · Edited 2
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.

Read more
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:
- No equivalent dashboard widgets
- Reporting deployment status to work items
- Separation of build and release (build once, release has multiple deployments of the build against stages)
- Missing Work item / commit diff report before deploying to a new stage
- You can’t view the test results at each stage
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.
Read less
- Silviu Author January 26, 2023 0
  
  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