YAML And Lessons Learned
This is the last part of the series. Let’s take a look at a couple of lessons I’ve learned and what we can do to further improve the whole thing.
There are more parts available:
Azure DevOps CI/CD for Windows Desktop Apps – Part 1
Azure DevOps CI/CD for Windows Desktop Apps – Part 2
Azure DevOps CI/CD for Windows Desktop Apps – Part 3
Azure DevOps CI/CD for Windows Desktop Apps – Part 4
Azure DevOps CI/CD for Windows Desktop Apps – Part 5 (this post)
YAML – Should I Bother?
I got feedback on Twitter to also cover YAML for writing pipelines and generally speaking, YAML has a couple of advantages and is considered as best practice or as recommended way to write pipelines. But what is YAML (yet another markup language) and should I really bother using it? Well, as always, it depends.
The build pipeline can easily be “converted” to YAML. Just click on the individual job or the agent job and click “View as YAML” at the top, right. Check out this blog post for detailed instructions: http://www.codewrecks.com/blog/index.php/2019/05/04/converting-existing-pipeline-to-yaml-how-to-avoid-double-builds/
Unfortunately this option is not available for release pipelines. I’ve read that stages and approvals are not yet supported in YAML, so for now it seems we have to stick to the visual designer if we want to use those features.
Converting into YAML has its benefits. Your “pipeline as code” can be tracked using source control, editing the pipeline is much quicker and reading the steps is also easier as you see the whole pipeline without clicking on every task first. It’s like reading a script.
Still, if you think you are missing out after you converted to YAML and think you have to learn a new syntax for building up the list of tasks, there’s good news. In Azure DevOps you can click on the task in the text editor and it will show you the visual editor, just like using the visual pipeline editor:
So in conclusion: YAML is definitely the way to go. I hope that the release pipeline can also be converted to YAML soon without losing any features around approval between stages. I do wish that the conversion from visual to YAML (or vice versa for that matter) becomes easier in the future. I’m not sure why there’s no “Convert” button to simply do what the blog post linked above describes. So there’s room for improvement…
Working with Azure DevOps pipelines can be frustrating. Sometimes things do not work as expected and sometimes it’s really hard to debug. You end up with trial and error approach which is very time consuming. So here’s a couple of things I learned:
Invoking CLI from PowerShell scripts
In my build process I had a PowerShell script which prepared a configuration file and at the very end, a CLI executable had to be invoked which got the config file just created passed on the command line.
Needless to say, testing this on the dev machine worked fine but as soon as the script was executed through the pipeline on the agent, it got stuck every time. The CLI never exited.
I’m still not sure why this behaved this way but I found a workaround where I split up the two steps:
- execute the PowerShell script to create the config file using the PowerShell script task
- execute the CLI with the previously created config file using the Command Line task
Remove-Item in PowerShell Scripts
Sometimes you need to execute a PowerShell script for cleaning things up. Removing files and directories. I had several situations where the Remove-Item cmdlet just didn’t remove the directory with the content. Again, executing it on the dev machine always worked. In the build pipeline it sometimes (!) didn’t.
I never got to the bottom of it but cleaning up the directories using the Command Line task with “rd /s /q” never failed.
Conclusion: if you see weird behavior from commands or cmdlets in PowerShell scripts which can’t be reproduced on your machine, consider replacing them with Command Line tasks.
I hope you enjoyed this 5 part series. I learned a lot while building my first pipeline and these blog posts should serve me to remember and also serve you to learn from my experience. Cheers!
CEO of code4ward GmbH and Windows lead developer at http://www.royalapps.com where most of the time is spent on Royal TS, a multi platform, multi protocol remote management solution, for Windows, macOS and mobile supporting RDP, VNC, SSH, Telnet, and many more.
Long time Microsoft MVP supporting communities on- and offline as well as speaking at user groups and conferences about DevOps and other software development topics.