Disable creation of classic pipelines

Silviu

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.

Screenshot of organization-level pipelines settings

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.

Screenshot of Pipelines side menu

When creating a new build pipeline, you’ll no longer be able to choose Other Git or Subversion as pipeline repository.

Screenshot of creating a new pipeline

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.

Screenshot of disabled new release menu

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

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

    • SilviuMicrosoft employee 0

      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

      • PandaSharp 1

        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 🙂

  • Graham Smith 0

    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!

    • SilviuMicrosoft employee 1

      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

      • Graham Smith 1

        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!

      • Nick Walton 0

        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.

  • Michael Taylor 1

    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.

    • SilviuMicrosoft employee 0

      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

  • Neno Loje 1

    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

    • SilviuMicrosoft employee 0

      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

      • Neno Loje 0

        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

        • Neno Loje 0

          PS: Oh, and a big one: there’s no Pull Request policy for deployments (there is one for classic release pipelines though).

          –Neno

          • SilviuMicrosoft employee 0

            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

          • Neno Loje 0

            Hi Silviu,

            Sure:

            • With classic release pipelines, I can add the release pipeline as a branch policy, so the result will be shown right within the PR.
            • With YAML pipelines, if a build pipeline triggers another YAML-based pipeline (for deployment), that second pipeline result does not appear in the PR (and thus cannot be made a required policy).

            Does that make sense?

            –Neno

  • James Snape 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:

    • 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.

    • SilviuMicrosoft employee 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

  • Dmitry Repin 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.

    • SilviuMicrosoft employee 0

      Hi Dmitry,

      The feature is currently available for Azure DevOps Services only.

      Best regards,
      Silviu

  • OSBORNE Luke 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 going to implement?

  • Patrice Scribe 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 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 ???

  • Mohamed Basher 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

  • Leverson Carlos 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

Feedback usabilla icon