At Made Tech, our company mission is “to improve software delivery in every organisation” and recently while using Azure DevOps, I’ve been feeling that currently, these two things are mutually exclusive.
Before I get started, it’s important to not confuse Azure DevOps with Azure’s cloud services offering. You can think of Azure DevOps as Github and CircleCI bundled into one package, whereas Azures cloud services is akin to AWS, or Google Cloud.
Now, I’ve already made a comparison between Azure DevOps, and Github and CircleCI. The latter are the tools that I use day to day out of choice because I feel that they let me get my work done in a way that I’m accustomed to following best practices in our industry. It’s only to be expected that when starting to use Azure DevOps over the past month or so, I’m going to compare it to these.
On the surface, besides a tricky UI to get used to, Azure DevOps appears to have all of the features you’d expect, and has good potential at being an all-in-one version control system (VCS) and continuous integration/delivery pipeline, similar to what Gitlab offers. However, there are a few niggles before I’ll be encouraging customers and others to use it.
As a developer, I’m passionate about being able to codify “all the things”. It means you don’t need to document as much for people if the code is written well, and it also means you can review code before merging it into your repository. It also means that you can easily duplicate and reuse existing functionality.
If we set aside the VCS element of Azure DevOps for now and focus solely on the CI/CD pipelines feature. CircleCI gives you a completely blank slate when you use the tool. You define your pipeline in code however you see fit.
Out of the box, with pipelines in Azure, you get both Build and Release pipelines. They are clearly segregated in the navigation. It’s up to you to define the implementation of each, but by having these two defined separately, Azure are trying to encourage a good practice of separating the logic of the two.
Build pipelines are responsible solely for building an artefact of your application, be this an executable or a docker image for example, and then running your tests and linting checks against this. It will then publish your artefact somewhere if everything passes, in effect, declaring it as fit for deployment. That is the end of the Build pipelines responsibility. Similar to CircleCI, your Build pipeline can be declared in YAML, or if you wish, a GUI. Being good developers, we obviously opt for keeping this defined in code so it can be committed into our repository.
When it comes to deploying your code, the Azure DevOps mindset is to now move to a Release pipeline. It’s great in that it gives a clear separation of the two pipelines. The Release pipeline will take a published artefact from a build pipeline and figure out how to get that deployed out to your various environments.
Here’s the bomb. Release pipelines can’t be codified. You have to build these using only the GUI.
So for the reasons I’ve already alluded to, this is bad for a number of reasons:
- It’s really hard to re-use these pipelines across projects. You can’t just copy the pipeline from one project into another, and therefore;
- Setting up pipelines is manual, therefore time consuming and fiddly, which could;
- Lead to mistakes being made that may affect reliability or security
I was quite surprised by how much I was affected by not being able to codify my deployment pipeline. It felt a little dirty and unclean for me as a developer. It hampers my ability to:
- work fast when setting up CD pipelines by being able to reuse existing pipeline code
- keep the pipeline reliable and reviewable before changes are merged into it, making it more secure
- not needing to document the pipeline separately with how it is set up and configured
These practices, along with many others, are what we pride ourselves on at Made Tech – doing things the best way we possibly can, based on our experience over the years, and adopting best practices within the industry that we then do day-to-day without even thinking. It’s what helps us deliver good quality products to our customers.
So with these downsides, I was trying to stay positive, and look for an alternate solution that could work, and knowing that the build pipelines could be codified, I started looking into perhaps utilising those for everything instead and ignore Release pipelines altogether.
You can get quite far with this approach, as the build pipelines are highly scriptable to do whatever you wish. As with CircleCI, behind the scenes you just have an image of your choice, be it Linux or Windows, booted up for you, and you write scripts. The stumbling block was the inability to have manual intervention steps, whereby a release to production was guarded by an approval button. So very close.
Word is, that Microsoft is working on the ability to codify and in fact unify build and release pipelines, however, I’ve been told that the feature has already been pushed back once previously, so there is no knowing when it will be ready to use. The current estimate is by the end of Q1 this year. Though we’re now in April, Q2…
About the Author
Senior Technology Adviser at Made Tech
Code, coffee, cake and Eurovision. In no particular order.
