Continuous Deployment Models

When deploying new software releases to servers or (insert <noun>-as-a-service> here), its a good idea to either deploy the releases in a controlled manor, or to have a quick rollback plan. In this article, we will be diving into blue/green deployments, canary deployments, ring based deployments, and feature tag deployments.

blue/green Deployments

Blue/green deployments are a deployment model where a new version of the application never gets deployed to the production servers (green) directly. Rather, it gets deployed to another set of servers (blue) first. Since the blue servers are not currently serving any traffic for users, the deployment has no impact at all. Once the deployment has completed successfully and tested, users are directed to the new deployment (blue). You can direct all user traffic, or a subset of user traffic if your load balancer supports it (referred to as 'Progressive Exposure').

This process is then repeated with the next release. Blue would be the current production environment, so you would deploy to the green servers first. This model requires two sets of identical hosts, and a load balancer or reverse proxy in front of them. If there are any unexpected issues with the new release, it is very easy to switch back to the previous release. The disadvantages to this type of model is that it requires having redundant environments (and potentially wasted resources).

There is an alternative method of blue/green deployments that is referred to as "immutable servers". This method is identical to blue/green deployments as described above. However, after switching user traffic over to the servers with the new release, the old servers are destroyed after a period of time. They are not used again. This type of model becomes particularly efficient when using a pipeline that is capable of creating servers for you (i.e. Azure Devops Pipelines)

Canary Deployments

In a canary deployment, not all users are routed to the new release immediately. Only a limited percentage of users get access to the new release. These users are the canaries. They should be monitored closely, so it is important to be using monitoring software that is capable of looking at the statistics of a web application from the users' perspective (for example, Application Insights). Over time, the number of canaries can increase until all traffic is directed to the new release. The biggest advantage with this method is limited exposure of issues. If an issue appears after the release is deployed, only a small subset of users will experience it. After you fix the issues and redeploy the release, its best to select a different group of users to be canaries.

Ring Based Deployments

A ring based deployment has multiple production environments. Each production environment serves a limited number of users. It's similar to a canary deployment. However, with a ring-based deployment, you can have as many production environments as you want. New releases are deployed to the rings one by one over time, until all rings have been updated.

Feature Tag Deployments

Feature flags are used to slowly expose new features to sets of users. Unlike the other deployment models, they are not implemented in the infrastructure. They are typically implemented and enabled in code. An example would be a feature flag in a database that gives users access to a button on your web page. A developer could enable the flag for a set of users. These users would be able to see the button, other users would not. Feature flags can even toggle bug fixes or performance improvements.

My next article will cover implementing blue/green deployments in Azure using Azure Devops and App Services.

comments powered by Disqus