Deploying new features is often risky business, especially in a high-volume production environment. A bad bug can take down your entire app or affect your user base.
A percentage-based rollout (percentage rollout) gradually introduces a new feature to an increasing percentage of your users over time after the feature is deployed to its final destination.Â
Percentage rollout is an iteration of dark launching, in which you silently deploy code to separate deployment concerns from product and marketing concerns and end-user behavior. After deployment, your product team controls the release by incrementing the percentage of users with access to the feature—often by using feature flags.
Feature flags—also known as toggles or switches—are strikingly well-suited to percentage rollouts. It’s difficult to successfully implement a percentage rollout without them. Most feature flag management systems allow you to target users by any attribute. By wrapping your feature in feature flags, you can easily toggle code execution for any subset of your user base. Even more critically, there’s no need to re-deploy if you need to roll back a feature when something goes wrong.
In this post, we'll first add some context around percentage-based rollouts by looking at various types of rollout options and strategies, and then we'll rundown seven reasons percentage rollouts will help you reduce risk.
In context: Rollout options
Let’s take a step back and briefly consider some alternatives to see the value that percentage rollouts offer.
At some point, you’ll need to start your rollout to production. The terms "deployment," "release," and "rollout" are often used interchangeably, so it's important to understand the differences:
- Deployment: code or software is moved from one controlled environment to another, typically from development to production. However, pushing software to a user's environment doesn’t necessarily mean the user gains access to it
- Release: exposes software or features to end-users, giving them access
- Rollout: process of deploying and releasing software or features to users
A few different ways to roll out functionality can be broadly categorized into established strategies. A rollout strategy is a plan or systematic approach to introducing new features, upgrading an application, or moving users to a new system or interface.
Full rollout—also known as big-bang adoption, direct changeover, or one-and-done—is a deployment and release strategy that makes code or features available simultaneously to all users for whom they are ultimately intended. It’s the riskiest rollout strategy and the most difficult to remedy in the event of a failure, so it’s best used to release critical security patches or features with a low probability of destabilizing your application.
Alternative controlled rollout strategies
A controlled rollout gradually introduces code or features to parts of your user base before making them available to all intended users. Here are four examples:Â
Canary releases
A canary release lets you safely test a new feature by releasing it to a small subset of users that represents the general characteristics of your user base. You can populate this subset at random or by explicitly selecting users or a user segment.
Ring deployment
A ring deployment manages risk by making code available to a small group before gradually including additional groups until your entire user base is represented. The release follows the same pattern as deployment, either immediately or following a dark launch pattern to manage deployment separately from release.
Users in each group should opt in or have a set of attributes in common. For example, a common pattern deploys to internal users first, then beta users, and then to the rest of your users.
Entitlement releases
An entitlement release gives certain users access to exclusive features or releases, called entitlements. For instance, on a subscription-based platform, you can restrict a release to users with a subscription or premium members.
Targeted releases
A targeted release makes a feature available simultaneously to all users in a subset based on an identifier or segment, such as geography, industry, or interaction pattern.
7 ways percentage rollouts minimize deployment risks
Percentage rollouts are most appropriate in a user base with little variation. Selecting users randomly is likely to provide an accurate representative sample of your entire user base.
However, some of these strategies can be combined. For example, you can implement a percentage-based entitlement release, which incrementally releases a feature but stops short of making it available to your whole user base. Or, you can structure a percentage rollout by following a blue-green deployment model. A percentage rollout helps us minimize risks in a couple of ways:
1. It’s safe and flexible
In contrast to a traditional full rollout, which is somewhat aggressive and exposes all your users to potential release complications, a percentage rollout allows you to test your capacity first. You initially push the feature to only some of your users to ensure it works as intended before risking the added capacity and configuration complexity of an all-out release to your whole user base.
A percentage rollout release also gives you granular control and observability, so you can quickly adapt. Each incremental release provides immediate feedback and presents an increasingly clearer view of the feature’s total impact on your entire user base and your infrastructure. If an error or performance issue manifests in a small user population, you can catch it and pause or reverse the process before exposing more users.
2. It limits the scope of errors
Percentage rollout lets you control the scope of impact of potential issues since only a limited number of users get to see the release. This enables you to contain its negative effects to prevent it from affecting user experience across your entire application.
3. Kill switch for easy rollback
If containment becomes unmanageable, you can quickly roll the feature back to development to make revisions. Because features in a percentage rollout are tied to feature flags, rolling back a change is a matter of toggling the feature flag's switch—which is usually just a GUI element.
4. You can iterate to refine a feature
You can take advantage of a percentage rollout’s granular feedback characteristics to better tailor your feature to your business goals. A percentage rollout gives you precise control of a feature’s availability, down to very small portions of your user base, which lets you gain and apply immediate feedback on small iterations.
5. Enables you to better meet customer expectations
When deploying new features to production, one of the most significant risks is how customers will react to the changes and whether the new features meet their expectations.
Once your application goes live, it’s helpful to be able to monitor user response and correlate it to specific changes. This is difficult to achieve in a full rollout, in which the noise of releasing to all users at once masks the impact of individual factors that contribute to user response.
A quicker feedback cycle lets your organization provide more value to users and maximize revenue and conversions. You can also use feature flags to identify strong product ideas in A/B testing before starting your rollout to production.
6. Saves development costsÂ
Percentage rollout offers a timely and responsive way to catch bugs and vulnerabilities in your releases before they make it to production. Since it's much cheaper to make changes early in the development, this strategy can save a substantial amount of money that would otherwise go into the cost of salvaging a failed release and remedying disrupted business operations.Â
7. Application in a progressive delivery pipeline
A typical use case for percentage rollouts is to implement a progressive delivery pipeline in which the focus is skewed more towards code quality rather than code volume.
Major companies like Facebook, Microsoft, and Google often use percentage rollouts in their progressive delivery strategies when launching new features.
Wrapping up
In contrast to a traditional full rollout, in which deployment and release coincide with a whole user base, you might not always want to make a new feature available to all your users immediately. Feature rollout doesn't always occur linearly but instead often follows a complex process involving back-and-forth between developers and users. Sometimes, it’s safer to introduce new functionality incrementally as a gradual, percentage-based rollout.
Using feature flags, you can safely implement a progressive delivery process that lets you introduce new code and features—and their accompanying risks—in a controlled, gradual process.
.webp)
.webp)
