DevOps for your Organization – Part 9: Release Gates and QA Approval
In the previous post, we demonstrated how to deploy your generated package to a test environment in Azure. In this final post, we will be cover:
- What release gates are,
- How you can use them within your organization, and
- How to configure them in Azure DevOps
What are release gates?
Release gates interrupt the automated release of code to an environment. They can require human intervention, wait a predefined amount of time, or perform an automated check with internal or external systems to determine if the release should continue.
Release gates can be used both before code is released to an environment and after code is released to an environment. You would use the former when you want to exert control on what gets deployed to an environment and when. You would use the latter when you want to capture sign-off on the code that is released and control how the release moves on to the next step.
Microsoft’s article Release approvals and gates overview goes into great detail about what gates are and what Azure DevOps supports.
How can you use them within your organization
Release gates can be used to achieve several goals within your organization. Perhaps you want to allow each developer to control when their environment is updated, or you wish to have QA sign off on a release before it leaves a test environment. It can be used to release to production in rings to minimize the blast radius of new releases. We have used release gates to achieve the following:
- Clients sign off on the implementation of new features by approving their release from staging to production.
- QA approve changes going into their environments to isolate code changes and test features in isolation.
- QA approve changes leaving their environments to say that the code changes have passed QA.
- Project Manager approves releases to production
- Developers can control when configuration changes are pushed to their environments
Since all approvals are logged by Azure DevOps, we have a trail of who approved the changes and when. This kind of logging becomes more important when the stakes become higher (client sign-off, releases to production, etc.).
Controlling your development environment
We have found that release gates are particularly useful in Dynamics 365 development environments. Imagine that two developers may be working on an entity or form at the same time. One developer finishes his feature and checks in his code. If those changes are immediately pushed to the other developer’s environment, he will lose the work that he had previously done. If those changes are never pushed, their environments will get out of sync. Developers will need to do more and more to resolve the merges of their customizations
The solution to this problem is to have the first developer’s changes queued up to be released to the second developer but giving the second developer a means to delay the release of those changes. We would achieve this by using a release gate. When the second developer has exported all of her changes and is ready to receive other customizations, she can approve the release to her environment.
This setup ensure that developers are doing the right thing by synchronizing their environments but gives them autonomy over how and when changes get released to those environments.
Accumulate changes to the test environment
Code changes and new features ought to be tested in isolation. As QA is testing new features, they should be working on a stable environment; new releases shouldn’t be hitting the QA environments in the middle of their work. Thus, QA engineers should be given the same authority over their environments that we described above. They should be deciding when new code changes are pushed to their environments, and which versions are going in.
These releases to the QA environment can be accumulated. For example, imagine that 3 developers finish new features on the same day. They all want to queue their changes to be reviewed by QA before they complete the pull request into the master branch. They can each trigger a release to the QA environment.
Because the QA engineer must approve releases to the QA environment, the code does not immediately get released, but rather simply puts them into a queue. The QA engineer can release those changes in whatever order he decides (priority-based, complexity of testing the feature, which developer he likes most, etc.). The selection process does not require the developers and QA engineer to coordinate on when to release what where. Indeed, each developer does not even need to know that the others have finished features on the same day. They simply submit their code for testing. This allows for selective ignorance on everyone’s part, relieving them of the responsibility of figuring this problem out. The system handles the process for them.
Once the QA engineer has finished testing one of the features, they can alert the developer whether or not their code passed or failed and approve the release of the next feature.
Release to production
Whether or not to automatically deploy your code to production depends on the maturity of your DevOps process. In a mature process, substantial unit testing will catch bugs early in the development cycle and robust monitoring will flag service degradation rapidly. Having this infrastructure in place gives organizations the confidence to release to production in an automated way.
However, in this blog series, we are working under the assumption that your DevOps process is nascent, and that your organization does not have such a mature environment. For that reason, we will advise for releases to be approved by the project manager. She will be the one with ultimate authority over when to release the code. Luckily, with the setup that we have advocated over the series, if there are any outages caused by the release of bad code, a previous version can be deployed with a few clicks.
How to configure release gates in Azure DevOps
In the interest of keeping this article evergreen (and to not recreate the work that others have done better), I will simply point you to Microsoft’s documentation on this:
Let Us Help You Out!
And that brings us to the end of our DevOps for your Organization series! If you have any questions or need any clarifications, feel free to contact us at contact@codevanguard.com.
Code Vanguard has worked with clients of all sizes, helping them to use DevOps practices to accelerate their time to delivery. If you’d like Code Vanguard to help your organization with your DevOps process, feel free to reach out to us!
This post is part of the DevOps for your Organization series, where we walk through some basic steps you can take to move your organization towards the DevOps process. The full series can be found here. If you’d like Code Vanguard to help your organization with its DevOps process, feel free to reach out to us!
