Azure DevOps CI/CD — Release Pipeline Best Practices
Implementing CI and CD can be daunting. Thats why Azure DevOps (ADO) is here to make that a much easier task. Whilst we’ll ignore the other tools and benefits ADO provides and focus entirely on build and release pipelines, those alone can save you and your company’s time with just a little upfront effort. But how do you structure CI/CD into your project to get the most out of it and streamline what can be a laborious process.
Before implementing CI/CD on your project remember that it’s not going to be perfect first time. In reality it will never be perfect, there will always be “the next step”. However, every step will be advantageous and whilst we won’t be focusing on the process of compiling your project here (you can find countless resources on that), we will look at how to utilise the often overlooked release pipelines in Azure DevOps.
The Strategy
Let’s start by making a clear distinction between building and releasing:
- Building is the entire process of generating a package which is to be deployed.
- Releasing it is sending that package to be to be deployed and in most cases, even deploying it.
That might sound obvious but it is crucial in utilising the release pipeline and optimising releases in ADO. With that out the way let’s look at the first tip.
Build All Environments At Once
With ADO, you don’t have to worry about storing your packages in a safe place whilst they are waiting for a release. So there is no reason to produce a new build for each environment when you need it. Do it all at once, even if that means you have 4 different packages sat as separate artifacts on the same pipeline.
There are several benefits to this:
- Compilation Speed — Building the a second environment after the first one has just finished is much quicker that starting again in 2 weeks.
- Deployment Speed — When you’re ready to deploy the builds sat there waiting
- Reliability — You know whats been tested on the System Test environment is the same as what will be sent for User Acceptance Testing and Production.
Making Use Of Release Pipelines
Remember that you can, and should, separate out the release from the build. It will give the following tips a much bigger impact on your project. At first, you might just use the release pipelines for emailing the package to somebody for manual deployment. That is a good, and valid, first step. The next step might be copying the files directly to the server into a temporary folder. What’s important here is that each step you take you are getting closer to the goal of fully automated deployment.
Automate Package Configuration on the Release Pipelines
Unless it needs to be embedded into the package during compilation, do not update your config files in the build process, wait and do it in the release pipeline. One of the biggest concerns we are covering here is security. Configuration files might contain sensitive data that needs to be kept private. We can make use of the secure files feature ADO provides to do that, rather than adding the sensitive data to the artifacts on the build pipeline. Get the sensitive data from the secure files, use it, deploy it and throw it away, don’t leave it hanging around.
However, the key to take from this is that the configuration of a release is automated. Nobody wants to be manually updating config files after the deployment has taken place. It introduces unnecessary risk and is more reliable to let automation take care of it.
Stage the Releases
A great way to breakdown the lifecycle of a product is in the release pipelines on ADO. If you’ve built all your environments at once you can hand over those artifacts to the release pipeline and let it take care of the rest. Ensure you map one stage to one environment. This makes it clear to anyone who looks, what environment and what customers have what release.
Gate Your Stages
Implement gates on your release pipeline at the begin or end of each environment and get people involved!
Let’s be honest, no matter how much we implement and chase the DevOps dream, it is never a sole developer’s decision to go live (unless of course it’s an individual project). You can gate a release out of the testing stage by having the lead testers approve the release prior to the customers accepting it. Or bring in service managers to approve releases into a customer environment. You could even make work item queries of things that must be done before it can be released to an environment, if you have external jobs to run.
It cannot be underestimated how powerful gating environments can be. From getting team members involved in the release process, ensuring a release is authorised to go out and making sure there is no one single point of failure.
If implemented effectively, it will stop all those pointless emails flying about and cut down documentation drastically. Freeing up you and your team to do the important stuff.
Iterate
As mentioned earlier, CI/CD release pipelines are never perfect and can always be improved. Look at if your still performing any manual processes such as:
- Progressing work items
- Producing release notes
- Updating Version Numbers
What about improving quality?
- Automated Unit Tests
- Gates on Pull Requests
- Checking if Test Scripts have passed?
Always start small and think how can you achieve the next step. No company is going to give you a month off from development to complete CI/CD for your team but they might give you an afternoon a week to improve the process. Think how you can make your own day and your teams day an easier one.
