Hello!

This is the first in what will probably be an on-going topic around how to “Do The DevOps” right. And it’s going to be on-going because there is no ‘right way’ of doing things. I’m going to focus initially on what people most likely first think about when they hear the phrase DevOps, and that is pipelines. More specifically, I want to talk about tasks that are available out of the box or via the marketplace. And, even more specifically, I am going to talk about the Azure DevOps pipelines, because that is what I have been mainly working on lately. But this subject can also be applied to pretty much any product that takes some code from a repo, runs some magic on an agent that is not a developers machine, and pushes it out to one or more environments.

The concept of using tasks that can only be run via a proprietary agent has troubled me for some time. Back long ago when we had nothing but msbuild files to run build and deployment processes via TFS there were not that many resources available, and so you had to get creative using cmdline, or using some random library you found on the internet like MSBuild Community Tasks, or using Property Functions in MSBuild, or using pre-build steps in .sln files, or some post-deployment steps via something like WiX… basically, pretty much everything you needed to do you did in-house, and how sophisticated it went was largely irrelevant as long as it got the job done.

So when things like Octopus Deploy hit the market and Microsoft bought InRelease the concept of tools that recognised the both the complexity and high reusability of release tasks meant that we could write tasks in a tool and share them out across teams, and even publish them to a marketplace. Neat!

So if I find them ‘neat’, why do I also find them ‘troublesome’ to the point of asking if they’re evil? Well, the first challenge is that downloading code you find on the internet that sort of does what you need is not just limited to StackOverflow: there’s no guarantee of quality coming from any of these marketplaces.

Secondly, one of the reasons that build/release yaml files are stored in source control along with the code is so that the process is versioned. If this code is beholden to some random marketplace task that may take a casual attitude to semantic versioning and updating the task version number then you could be heading for a world of pain. Or even worse it might disappear entirely. If you think that is unlikely, you’re correct, but it has happened before: consider the consequences of when left-pad was pulled.

Another issue is that it then makes it impossible to run a proper build and release process locally prior to checking in, which begs the question of how the developer managed to set up an environment to do development in the first place.

Not only is there reliability when it comes to using the marketplace, you’re then stuck on the same build and release platform as all your yaml pipelines rely on tasks written specifically for that platform.

There’s probably more, but I think so far I’ve highlighted enough issues to justify being pensive about using tasks that can only be run in a build/release pipeline.

But it’s not all bad news, as in part two I’ll discuss the advantages before summing up.