Azure Pipelines YAML Definitions - Initial Thoughts

I recently set up a new instance of Azure DevOps for a client I am currently working for, and as a result I was introduced to the new YAML pipeline editor.  I've defined simple builds in YAML before when writing a CI/CD pipeline for Travis, so I was eager to see how Microsoft's offering compared.  I had seen a tweet recently about how they had added a task picker interface on the right-hand side, which looked like it would make it a lot easier to insert code for the various tasks one might want to add to the pipeline.

However when I first started to setup the pipeline, I was unable to find this menu.  At first I thought maybe I had seen a preview feature which was not yet available to everyone, but no amount of googling or searching could answer that question for me.

I eventually was able to copy/paste some YAML output from a previous proof of concept Azure DevOps installation I had setup.  This wasn't ideal though as I had hoped to use the new task picker menu instead to make things easier.

As it turned out, the menu on the right-hand side is only visible after you initially save and run your build pipeline.  This was a bit disappointing to be honest.  Why would you be offered no guidance when being faced with a YAML build for the first time, and be forced to save and check-in your first unguided attempt, before being given the tooling to make it a lot easier?

I've been having discussions recently with friends and former colleagues about the benefits of having the pipeline defined in YAML (or any text format for that matter) instead of the old way, where it was handled by the WYSIWYG editor on Azure DevOps/TFS.  So far the only thing I can come up with as an advantage is that the build definition lives with the code and can be perhaps be more easily converted to another format, thus making your solution/definition more portable.  One advantage of having the file in the git repo, I suppose, is it'll be updated alongside tasks you are working on and thus it's revision history can be more easily seen and related to changes in the code. Also I'm hoping that in future it will also be possible to run a YAML build locally, to save having to make commits just to check if it works properly. That would be very useful and I'm sure is in the pipeline, no pun intended.

That being said, I'm not sure the benefits mentioned above outweigh the ease-of-use and click, drag and drop experience offered in the "old" editor.  I could totally understand if there was a build file created as the output of this process, but to be forced to edit the file as text doesn't feel like a huge benefit to me.  I would rather see the old GUI when editing the pipeline, instead of having to remember what valid values are for each of the YAML properties, when I'm trying to update/tweak a task I have already defined.

My workflow just now is to use the sidebar helper menu to insert a new task with the new values I'd like to use, and then deleting the old one.  Not exactly ideal.  Hopefully in future Azure DevOps will be updated to show the sidebar menu populated with the values from the current task the caret is on.

In summary, I'm reluctantly sticking with the YAML pipeline definition for now, in the hope that the main benefits of doing so will be realised at a later date, whilst secretly enjoying myself defining the Release definition using the familiar WYSWYG editor.

Please feel free to sound off in the comments if I'm missing something obvious.

Gareth Oates

Gareth Oates

Oslo, Norway