A first look…
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
- 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.