Last week we compared the look and feel of classic and YAML pipeline creation, today - we will compare further technicalities of both pipelines
I will try to provide further insights that can help to choose between classic and YAML pipelines
History:
One common argument in favor of the YAML pipeline is that its history can be tracked easily as it's stored in a repository
even though this is true,the classic pipeline also has a history section that can very well be used to compare and track the changes
Let's edit the Maven task and enable sonarqube analysis
Navigate to the History tab to examine the history
click on "Compare Difference"
we can clearly see what has changed on line #93, the value of sqAnalysisEnabled has been set to true and this corresponds to us enabling "Run SonarQube or SonarCloud analysis" in the GUI
Both YAML and Classic pipelines provide almost the same level of traceability of what has been changed
However, if we try to find out why a certain change was done in a classic pipeline, we will be at a loss
YAML pipeline is a clear winner in the why aspect of the change, because in the git repository, it is possible to link a workitem to a commit or a pull request
Viewing the associated workitem provides us with complete information on why a change has been made
for example, SonarQube might have been enabled because of a requirement from the security team
Rollback changes:
It might be a cakewalk to revert changes in a git repository where the YAML pipeline is stored
however, even classic pipeline can do this as well
From the history tab find the last known good version and click on "Revert Pipeline"
That's it , the pipeline will be reverted to the the specified version
so about the rollback of changes both pipelines provide almost equal features
Collaboration:
Let's say 5 DevOps engineers could work on a pipeline at the same time
In classic pipelines, this is not possible but a YAMl pipeline being in source control solved this problem already
multiple developers can easily collaborate and even if there are merge conflicts, source control can easily handle the conflict resolution
So YAML pipeline is a winner here!
Peer Reviews:
If a YAML pipeline is used, the pull request workflow can be used to peer review pipeline changes before introducing the changes to the system
peer reviews not only do quality control on the pipeline code,but they also serve as excellent means of sharing the happenings with other DevOps engineers
we enabled SonarQube in classic pipelines, if we were to do it in YAML pipeline, we will be adding specific tasks in the YAML pipeline and then create a pull request
the reviewer of the pull request can get a complete understanding of what has changed as well as why things have changed (from the associated workitems)
In this way, there won't be any dependency on a particular DevOps engineer and they can peacefully enjoy their vacation
Release Pipelines:
Classic release pipelines provide a way to create continuous deployment pipelines which are separate from build pipelines
These pipelines are helpful if you want to follow the "Build once deploy anywhere" principle
click on "New pipeline" from the "Releases" section
After the configuration of different stages, the pipeline will look like the below
The release pipeline will consume the artifact created by the build pipeline and deploy it to various environments
In this way, the build and release processes are loosely coupled
Feature Availability:
With regards to the feature availability the YAML pipelines are catching up fast with the classic ones
you can read the detailed feature comparison on this Microsoft's page
Even though Microsoft is encouraging the use of YAML pipelines and working on reducing the feature gap between classic and YAML pipelines,A Senior Product Manager of Azure DevOps has confirmed here that the "classic release pipelines are not going anywhere"
Summary:
We have compared the classic and YAML pipelines in Azure DevOps with regard to various aspects, ultimately the choice will depend on the people and the magnitude of the project
If I were to select a pipeline for a project with less than 10 pipelines and newbie DevOps engineers, I would start with classic build and release pipelines
The GUI will bring in all the convenience for the DevOps engineers for the creation of the pipeline
and as the number of pipelines is less, we don't have to worry about replicating changes
we can migrate to YAML pipelines if required in future
If I were to select a pipeline for a big project with more than 10 pipelines, I would straight away start with YAML pipelines
what will you choose? Let me know.