Coming from the open-source world, you’re probably used to GitHub actions and being able to set up your pipelines quickly. No drama. Nice and simple. Simple projects, simple solutions.
If you’re in the corporate world and need something more substantial, Azure DevOps has been and continues to be the standard for making more complex pipelines. Because Azure DevOps has been around the longest, companies have already invested a lot of time building pipelines. When Infrastructure as Code became hot, Azure DevOps was slow to bring out its much-heralded YAML pipelines. Until that point, it was GUI-built pipelines only. Azure DevOps, however, was the first mover and therefore became the defacto choice for many global companies for both on-premise and in-the-cloud CI/CD.
And so, belatedly, YAML pipelines appeared in Azure DevOps. And lo, confusion reigned over the land. Depending on your local policies in place (and if you could make sense of the complicated ADO authorisation schemata), there might be a well-templated set of pipelines for one team, a set of messy hacked-together sprawling pipelines for another.
While Azure DevOps does have templating for YAML pipelines to allow re-use, this requires a policy of re-use, inner sourcing and (to a certain extent) control to be in place. If as an organization you centrally control how pipelines can be built, you’re not doing DevOps right. You want your DevOps teams to own their pipelines and be able to choose to reuse templates – but don’t enforce this.
Therefore Azure DevOps can make it hard to be consistent and flexible across your organisation without carefully planning what you need to do. Additionally, Azure DevOps being a SaaS solution, can implement seemingly ad-hoc changes to behaviour which breaks things. This was more prevalent when more active development occurred on Azure DevOps. These days GitHub is perhaps the CI/CD platform for the future, but still, it’s a risk.
The dangers of long pipelines
The best CI/CD pipelines are the shortest ones. Taking advantage of Azure DevOps features such as variable groups, environments (for limiting deployments to sensitive environments) as well as templates makes for cleaner pipelines. And these have the advantage of a lower support burden and clearer action paths when something goes wrong.
The longer the pipeline, the more brittle it becomes. The more code you write, the more chance of something going wrong. Often the temptation (or perhaps it’s better to say the dream) of Continuous Delivery is to automate everything from code check-in to production deployment. Teams or individuals often see this as the “definition of done” for CI/CD. That is in itself an anti-pattern. I’ve seen this many times in naive CD implementations. A long pipeline that does everything and delivers to every single environment along the way with break-out points for manual validation.
If you insert steps for manual approval of what the pipeline is doing then you are by definition inhibiting the flow of software change. There is no real difference between doing that and running the Change Approval Board (CAB) just like in the “bad old days”. You’re still letting people decide whether some software should be released or not when your pipelines and your automated tests should be telling you.
Getting Fast Feedback
In order to take human approval out of the process you need to ensure that your automation work smoothly. In order to do that you’re going to need to test them repeatedly. To minimise the time you spend on that, you want fast feedback. This applies to your code build and deploy procedures as well as the creation of the pipelines themselves.
Unfortunately, Azure DevOps has no built-in (pre-commit) validation mechanism for yaml pipelines. So how do we get fast feedback? The developer community has been vocal in identifying this also but yet, there are no truly simple, local solutions. One possibility is the VS Code YAML Validator but this uses a remote Azure function to do the validation (so potentially sharing your code with a third party) and it doesn’t handle templates:
Conclusion
Azure DevOps has become the de facto standard for building CI/CD pipelines in many organisations. The flexibility and power of the platform, not to mention the integrations with work item management, repositories, code scanning and repositories make it an attractive option. However, there are some DevOps anti-patterns that the tool falls into. Not allowing you to get fast feedback on pipeline changes, encouraging centralised administration and ‘gatekeeping’ tends to encourage long, complicated brittle pipelines unless carefully managed.
While there are many CI/CD platforms to choose from and they all integrate nicely with each other, Azure DevOps integrations are very powerful. The addition of the many extensions and marketplace apps for dashboarding makes it an attractive corporate solution even in 2023.
More reading
If you’re interested in the history of Azure DevOps and all the previous flavours such as Visual Studio Online and Visual Studio Team Services – here’s a great blog with dates and lots of facts and figures.