Release Strategies

Ring deployment

In a ring deployment, different groups gradually receive a new feature to manage the risk of deployment. These groups are represented as an expanding series of rings, starting with a small group and growing to encompass all your users.

If you do a ring deployment, choose users for each group based on a set of similar attributes or an opt-in process. Then make features available to those groups. For example, release to internal users first, and then beta users, and then to all users.

In a ring deployment, the release pattern mirrors the deployment pattern, which mitigates against the deployment itself causing a large unforeseen problem.

Percentage-based releases

In a percentage rollout, the deployment has already occurred and the release occurs incrementally based on a percentage. The new feature rolls out to 10% of users, then 25%, then 50%, until all users receive the new feature.

The users who get the new feature in a percentage rollout are randomly selected. After they get the new feature, they retain access to it as long as there is a way to identify them. This kind of sorting is best when your users must log in to use your product, or have accepted cookies.

These releases are useful when you cannot run a beta program, or there is little variation in your targeted user base. If you run a small B2B application with the same 1,000 monthly active users, a percentage-based release is likely to give you an accurate estimate of whether the full rollout is likely to have a positive or negative impact on your userbase.

You may want to automate percentage-based releases gradually by increasing the number of users receiving the new feature. You can terminate the release if there are too many errors or a response time exceeds a set threshold.

You can combine ring deployments and percentage rollouts. You first release to selected groups and then use a percentage-based release to roll out to the remainder of your user base.

Canary releases

A canary release lets you test whether a feature release will have a positive impact without affecting your whole user base. Only a small number of your users see the new feature you release, and you can target by user or segment to determine who those users are.

Ensure that the small group in your canary release is representative of your overall users. For example, a canary release that only goes out to people with the latest phones may miss problems that occur on older versions of a phone's operating system.

You can use a canary release to test both user acceptance and capacity management. If you roll out a new feature to a group and realize that it consumes too many resources, you can turn the feature off and refactor the product without having stressed your infrastructure or caused a bad user experience.

Targeted releases

It may make business sense to target a release based on some identifier or segment other than percentages.

For example, a food delivery service could roll out a new feature or set of related features to one medium-sized city to test how it works for multiple types of users who must all interact.

If that service makes a change that affects restaurants, drivers, and consumers, all of those users should receive the change simultaneously, since they all perform functions that relate to each other. If the city-wide rollout produces good results, the service can release it to the rest of its user base with confidence.

Entitlement releases

You might want a flag that affects user permissions or access to be permanent. These flags affect what users can do in your platform or their entitlements.

You can use an entitlement release to add a feature that is only intended for a portion of your users.

For example, if you had a premium service, you could configure the release so that the feature was only available to people who had paid a membership fee.

You can combine entitlement releases with percentage-based releases or canary releases, but when the release is done, only some users will have access to the feature.

BlueGreenDeployment

One of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. You usually need to do this quickly in order to minimize downtime. The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment - the blue one is now idle.

Blue-green deployment also gives you a rapid way to rollback - if anything goes wrong you switch the router back to your blue environment. There's still the issue of dealing with missed transactions while the green environment was live, but depending on your design you may be able to feed transactions to both environments in such a way as to keep the blue environment as a backup when the green is live. Or you may be able to put the application in read-only mode before cut-over, run it for a while in read-only mode, and then switch it to read-write mode. That may be enough to flush out many outstanding issues.

The two environments need to be different but as identical as possible. In some situations, they can be different pieces of hardware, or they can be different virtual machines running on the same (or different) hardware. They can also be a single operating environment partitioned into separate zones with separate IP addresses for the two slices.

Once you've put your green environment live and you're happy with its stability, you then use the blue environment as your staging environment for the final testing step for your next deployment. When you are ready for your next release, you switch from green to blue in the same way that you did from blue to green earlier. That way both green and blue environments are regularly cycling between live, previous version (for rollback) and staging the next version.

The fundamental idea is to have two easily switchable environments to switch between, there are plenty of ways to vary the details. One project did the switch by bouncing the webserver rather than working on the router. Another variation would be to use the same database, making the blue-green switches for web and domain layers.

Last updated

Was this helpful?