March 1, 2023
Approval Gates in VSTS Release Management was one of the many exciting Connect(); 2017 announcements.When approval gates were first announced my mind started thinking about all of the ways this could be used. I read Brian Harry's post and it gave me even more ideas. There were several questions I had about approval gates and here is the initial research I have done to help clarify a few things for me.
After this was announced, I went out to my VSTS account to try it out but the feature wasn't there. As I discussed in my previous post, I checked the preview features available to me and there was to enable. Also, here is a great article on how to start configuring the approval gates.
As I started thinking about post deployment approval gates, I immediately started thinking about automated tests and having those be an approval gate. However, I learned more and tried the approval gates. I see the inline tasks as some synchronous and something that can be immediately determined whether the quality control has passed or failed. There isn't a burn in period or something that is going to take some time to evaluate. Therefore immediate validations should continue as an inline task.
Post deployment approval gates introduce the ability to take the temperature of the deployment. This is something that isn't always available immediately. The approval gates can monitor the conditions until they have all been satisfied. This can be over a period of time and additional, it can even ignore a "start up" time to help minimize false positives. Another way to think of these is something that takes some time to gather once a deployment is complete. This could be metrics about the environment. If there are performance issues with the site it might some time for enough users to surface this. If there is post deployment manual testing occurring, it may take some time to verify that there aren't any critical or blocking bugs found. These types of checks are perfect candidates to use approval gates.
Approval gates can be used in any situation where required quality controls must be met before the release can be allowed to continue to additional environments. Most DEV > TEST > PROD scenarios fit this description. For most organizations, the primary quality control gate into DEV is the CI build however there are usually additional requirements to get into TEST and even more to get into production. Approval gates can be a great way to automate these. However, you can tell that approval gates were designed for Canary deployments. Canary deployments are a mechanism for rolling out deployment to small number of users and incrementing the number of users on the new version as long as the As they progress from to Ring to Ring, they can verify and monitor the quality before deploying to the next ring. This helps ensure that issues found in an earlier ring, don't make it to subsequent rings until they are fixed. Pre-Deployment and Post-Deployment approval gates can be used to ensure the quality in the current environment is met before going to the next environment.
The next question I had is when should I use pre-deployment or post-deployment conditions. Arguably similar gates could be used at both but the primary rule of thumb is that the gates should really be environment specific. Meaning, that any verification of the current environment should be done post deployment so once the approval is achieved, the release can begin the pre-deployment approval gates for the next environment. Pre-deployment approval gates should be specific metrics that must be meant for the current environment. This could be the same as previous environment or it could be more stringent depending on your process.
Here's a list of ideas that I have compiled that includes some of my ideas and also the ones I read from Microsoft.
Pre-Deployment Conditions
Post-Deployment Conditions
.png){kind=logo}
We're here to help you tackle what's next in your digital journey.
