Thoughts about disabling classic pipelines in Azure DevOps

Reading Time: 4 minutes

In this post I want to share my thoughts about disabling classic pipelines in Azure DevOps. Which I know there are mixed feelings about.

In addition, I want to raise awareness that this is now possible. Due to the fact that towards the end of January Microsoft announced that you can now disable creation of classic pipelines in Azure DevOps.

In other words, you can now disable the use of the GUI-based Classic Editor and the Releases features in Azure Pipelines. Like the Classic Editor example shown below.

Which means that if this setting is enabled your only option is to work with YAML pipelines. In other words, a pipeline consisting of code. For example, the above GUI-based pipeline would be the below YAML code instead.

steps:
 - task: PowerShell@2
 inputs:
   targetType: 'inline'
   script: |
       # PowerShell to extract contents of a database in a serverless SQLPool into a dacpac file
            
 SqlPackage /Action:Extract /TargetFile:$(Build.ArtifactStagingDirectory)\$(TargetFile) /p:VerifyExtraction=true /SourceServerName:$(SQLPoolEndPoint) /SourceDatabaseName:$(SourceDB) /SourceUser:$(SQLPooluser) /SourcePassword:$(SQLPoolpw)

 - task: PublishBuildArtifacts@1
 displayName: 'Publishes dacpac as an artifact'
  # Publishes the dacpac as part of an artifact within Azure DevOps
        inputs:
          PathtoPublish: '$(Build.ArtifactStagingDirectory)'
          ArtifactName: $(SQLPoolartifactname)
          publishLocation: 'Container'

Anyway, you can select this setting at either the organization level or the project level. However, I suspect after reading the advantages of YAML pipelines in the official announcement more people will be keen to change the setting at an organization level.

Personal thoughts about disabling classic pipelines in Azure DevOps

I do think that this setting is long overdue. Because there are a lot of advantages to working with YAML pipelines.

Plus, I am glad that Microsoft listed some of the advantages to YAML pipelines in their announcement. Because I have been asked in the past if there is anything in black and white from Microsoft relating to this.

Especially when alternative offerings only offer YAML as an option. For example, there is no GUI-based option when working with GitHub Actions.

Now, I know a lot of people are keen to keep using the classic pipelines. I fully understand that people do not want to learn how to work with YAML pipelines for one reason or another.

Especially in the data platform community. Where professionals want to focus on working with data instead of learning the Azure Pipelines YAML schema.

Microsoft offers help in this area. In addition to providing a lot of documentation about the YAML schema they also share a guide on how you can migrate your Classic pipeline to YAML.

In addition to the benefits listed in the official announcement there is one other thing like I like about them. Which is that they are a lot more portable than classic pipelines.

Example

For example, if I move a Git repository I can setup the same YAML pipeline again by creating a new pipeline in Azure Pipelines and pointing it to an existing YAML file. Like I show in my post on how to connect a database project in Azure Repos to Azure Pipelines.

Sure, if I move to a new project I might have to recreate variable groups and service connections. But I still think that it is a lot easier to select a YAML file than all the clicking and copying required to manually recreate classic build and release pipelines.

Plus, I can share YAML pipelines in GitHub repositories so that anybody can download them. Like I did for my last post about my homemade serverless SQL Pool Database Project. As you can see below.

I do think that classic pipelines can be good for demos. In fact, now and again I do cover how to use both types of pipelines in my posts.

Like I do in my post about deploying a dacpac to a serverless SQL pool. However, some of you might have noticed that I tend to cover working with YAML pipelines more.

Infrastructure as Code

I personally think that if you are working with classic pipelines you are not truly working with Infrastructure as Code. Because you are still using a GUI-based method. I know others think differently, and that is perfectly fine.

However, it can lead to some interesting discussions within larger enterprises. Depending on what has been stated in your architecture principles. Because they can be open to interpretation.

Final words about disabling classic pipelines in Azure DevOps

I hope this post about my thoughts about disabling classic pipelines in Azure DevOps has raised awareness about the fact that it is now possible. Plus, given some of you food for thought.

I know there are mixed feelings about this already. Due to some feedback that I have already received. Which is to be expected since everybody is different and we all think differently.

You are more than welcome to share your own views with a comment in this post.