So Microsoft decided to do a thing…

In my last blog I wrote about my home made tool called AzDoAPITools which is centered on automatically converting Classical Pipelines (aka Build Definitions) into YAML pipelines.

Well it turns out that Microsoft has been working on similar functionality and launched it 2 months after I released my tool.

In my last post i wrote about having to use the On each job / step to view the YAML source for it and having to copy paste the YAML into a own made YML file. then having to scour through the other properties to manually convert the other properties manually.

Well it turns out with Sprint #178 the Button is being replaced with the “…” -> “Export to YAML” Feature. According to Microsoft it will “generate YAML with full fidelity to the designer pipeline.”. Reason being the button was only able to view the web UI elements. At the time of writing (November 26th 2020) this feature is still being rolled out and might not be available.

UPDATE! my environment received the new update and I did a full-on comparison which you can read here

In this Blog post I will take a preview look at this functionality and see how it compares to my own written tool.

Microsoft like myself has been working on making the transition easier for using YAML pipelines. Which honestly is great because this was a very needed enhancement to the Azure DevOps product to have users make the step towards YAML Pipelines.

At the time of writing (November 26th) This feature has not been rolled out to my personal environment so I am using this excellent blog post by Microsoft instead to get a first view of the new functionality. When it will be rolled out to my environment this blog will be updated. Parts of this blog come directly from the Microsoft blog as an example

Microsoft has replaced the button in favor for an “Export to YAML” menu option which can be accessed when viewing the summary of a classical pipeline

This new functionality according to microsoft will export the following objects:

• Single and multiple jobs
• Checkout options
• Execution plan parallelism
• Timeout and name metadata
• Demands
• Schedules and other triggers
• Pool selection, including jobs which differ from the default
• All tasks and all inputs, including optimizing for default inputs
• Job and step conditions
• Task group unrolling

So this is more or less as what my AzDoAPITools Module does based on this functionality list alone. When I can put it to the test the actual differences will show. I must say I am really impressed with the love microsoft is giving the product with this functionality.

They state the following items are missing from their export functionality:

• Variable Export
• Conversion to UTC timezone

I must confess that I totally agree on the last option missing because that was one bit of coding which really stressed my mind and took some time when I was working on AzDoAPITools. Shifting timezones to UTC might lead to shifting days and with DST involved it can be a tricky operation to convert accurately. However leaving this out will require manual labor in converting to UTC time and might lead to faults when a shift of days is involved!

The variables bit is somewhat unclear to me what they mean with it exactly. Microsoft states the following:

“Variables defined in YAML “shadow” (hide) variables set in the UI. Therefore, we didn’t want to export them into the YAML file in case you need an ability to alter them at runtime. If you have UI variables in your Classic pipeline, we mention them by name in the comments to remind you that you need to configure them in your new YAML pipeline definition.”

I think what they mean with this is that if you have Build Variables set which are settable at Queue time they will not be exported. I’m also assuming that secret variables are not exported to YAML.

I’m not sure I agree on this point from a professional perspective but I can see why they made this design decision.

Ideally you really want your variables in your YAML pipeline either as a static variable or a runtime parameter (which is Microsofts YAML equivalent of their old settable at runtime variables) as I wrote at my earlier blog. This makes sure that all your pipeline management is possible from the actual YAML file rathen then partly YAML code / partly from GUI.

Then again having runtime parameters inside your YAML file will introduce a new level of complexity for end users. So their choice to skip these variables and have their users deliberately transfer those over with the choice to have them as parameters or as regular variables which can be flagged as settable at queue time and managed from the Build Definition wrapper makes sense so users can ease their way into YAML Pipelines.

I do hope that Microsoft has limited the scope of variable export to just secret and settable variables and not static variables too. That is something I will get to see once I have access to this feature.

Based on the blog post by microsoft I can see the differences between the build in functionality and the tool which I wrote.

The overlap:

• Single and multiple jobs
• Checkout options
• Execution plan parallelism
• Timeout and name metadata
• Demands
• Schedules and other triggers
• Pool selection, including jobs which differ from the default
• All tasks and all inputs, including optimizing for default inputs
• Job and step conditions
• Task group unrolling

The differences:

• AzDoAPITools offers a choice to have Task Groups as YAML Templates as opposed to always expand / unroll them
• AzDoAPITools offers means to automatically convert Schedules to UTC timezone taking in consideration of shifting days and DST
• AzDoAPITools will automatically export all your variables and convert them to runtime parameters when they have the settable at queue time flag
• AzDoAPITools offers distinct conversion of just Task Groups as templates or expanded / unrolled
• AzDoAPITools offers multi-pipeline support.

Based on what I’ve seen sofar in means of the blog post I can see that Microsoft did a great job enhancing their product. Especially for small companies and companies who have not invested in CI/CD a lot or are not using CI/CD to the fullest by using a “Create once, use many” philosophy. For those companies this new functionality is great and they will probably do not mind having to do some manual work in transitioning to YAML Pipelines.

However companies which have invested a lot in CI/CD or are more advanced users of it will often use Task Groups or are interested in (re)using pipeline bits as YAML Templates when going the YAML pipeline way of working. I think for those scenario’s my AzDoAPITools still offers unique functionality to make their way into YAML Pipelines.

This blog is based purely on the statements I have seen in the originating Microsoft blog. When this functionality is live for me this blog post will be updated to reflect first hand usage.

Thanks for reading and let me know what your opinion is!