Azure DevOps has this dropdown box for “Agent Specification” that I’d never paid any real attention to:
Couple flavors of Windows, couple flavors of MacOS (my heart goes out to the folks that need the MacOS agent), and Ubuntu 16.04. The assorted flavors of Windows I understood – some code expects certain pieces at certain versions if it’s going to build correctly, and it’s easier and safer to match up your deployment with the Windows version it expects than it is to try and match a Windows box up with what the code expects.
But the Ubuntu agent didn’t make any real sense to me. I’d hazard a guess that the majority of people using AzDO are using it to build and/or deploy .net applications. The Linux world has a stable of its own CI/CD tools in varying degrees of popularity and ease-of-use, and I suspect that Linux shops were attached to one or another of those before AzDO really came into its own. So why have an Ubuntu agent? Trying to attract Linux developers and devops guys into AzDO? Maybe. Couldn’t hurt anything, at any rate. Still, it seems like a feature someone would implement as demand warranted, rather than a worm tossed hopefully into the devops waters.
So I started fiddling with the Ubuntu agent, and I found one insanely handy use cases for it.
az cli on Windows agents expects to be run as .cmd or .bat files. I was never one of the Windows shell scripting black belts. I was great at batch files back in the day when you lived and died by autoexec.bat, but the condition statements, variable assignment/use, all the rest of the cmd syntax, none of that was my strong suit. Now, all these years later, I honestly don’t know how common cmd aces are or how strong they are with Windows shell scripting in a world that doesn’t really call for it anymore.
But change your agent specification to Ubuntu 16.04, and now the agent believes that whatever files you run are bash shell scripts. That lets you check .sh files into your AzDO repo and feel reasonably safe that AzDO will faithfully execute them with the Azure CLI task type. If you’re stronger with bash than cmd, this is lifesaving.
I know. There’s a holy war brewing about az cli versus powershell vs ARM templates. If you fall into either of the other two camps, you probably don’t care how az cli scripts run. If you’re coming in from a Linux background, az cli is pretty intuitive and bash should be second nature. I’m not going into the pro’s and con’s of each here – it’s a big argument and I’m not sure there is a “right” answer – but I thought it was worth noting that the argument is happening.
Of course, it’s also great for building/deploying native Linux apps (nothing’s quite as much fun as trying to figure out why something builds and runs great locally but dies on the server, only to find that it was Windows-style line breaks in Linux config files all along). It’s also great for automating Linux infrastructure – build out a VM or container with Linux az cli, then pump in another shell script to execute on build and your resource appears, configured as desired, for the price of a few minutes of execution time. Those are the use cases I think Microsoft expected.
If Ubuntu 16.04 doesn’t do it for you, you can always deploy your own agents and add them to an AzDO agent pool. Spin up a container, add the agent, do your build, spin the container down, and you’ve mostly replicated a hosted agent. I’m making this sound easier than it is – someone needs to have a chat with the Azure Container Registry’s security model, and have that chat with a blowtorch and a pair of pliers – but when you have it working, it’s clean, light, and fast.
