Controlled Rollout Use Cases
A controlled rollout is a feature rollout with highly granular user targeting. There are two basic types of controlled rollouts: those where a feature is released first to a certain percentage of all users, and those where it’s released to users according to a specific attribute, like IP address or location.
For the first type, the development team would start with the feature release, in production, to 1% of their real user base. If that randomly-selected 1% responds well — the team’s CX metrics have either remained the same or improved, and customer support hasn’t seen any significant increase in tickets — they will release to 10% of users. If those users also respond well, they can roll out until every user sees the feature.
For a few examples of the second type: the team could release a feature first to New York, then to the entire United States, and then the rest of the world; or, some number of users could volunteer to beta test new features, and the development team could select those users by a user ID, releasing the feature only to them.
These types of controlled rollouts are often combined: for example, a team could select only internal users by IP and release to them, then release to the beta test user group, then release to 1% of the entire user base, then incrementally roll out to everyone.
If at any point there is a problem in any of these processes, the team should be able to implement a quick rollback to the previous version.
How to Implement Controlled Rollouts
One of the most common ways to implement controlled rollouts is using feature flags and feature management systems.
Many feature flag management systems come built-in with targeting capabilities, allowing you to target users based on just about any metric. You can use this capability, not only for controlled rollouts, but also for creating subscription models, hiding features behind paywalls, and merging unfinished features to trunk with their feature flags turned off.
Not only do feature flags make the process of targeting easier, they make rollback as simple as the click of a button. You don’t even have to re-deploy your code: simply flip off the feature toggle and your application is back to normal. You can now easily fix the bugs without having to worry about the impact on users (you only mildly inconvenienced 1% of them) and re-deploy afterwards.
