How to Enhance Phased Rollouts with Feature Flags

When releasing a new feature, we recommend that you never roll it out to your entire user base at once. Instead, it’s considered a best practice to roll out the new feature to segments of users at a time. Feature flags make it easier than ever to conduct phased rollouts, analyze the results, and enable continuous delivery.

Which rollout strategy should I use?

Oftentimes, users may think of a new feature release as simply toggling a switch on. In reality, developers use different strategies to ensure a seamless user experience and minimize risks. There are three key methods of feature rollouts. We’ll explore the pros and cons of each.

Big Bang Rollouts

Big bang rollouts consist of releasing a new feature or switching over to a new system all at once. In this one and done strategy, updates are live everywhere as of a certain day and time.

Big bang rollouts require substantial planning to ensure a smooth release. This method has the lowest cost of the strategies we’ll discuss, but it also presents the highest risk. No matter how much planning you do in advance, you can’t anticipate every potential error that will happen upon rollout.

One benefit of big bang rollouts is the ability to see ROI right away. Since your new feature is deployed to all your users at once, you can start seeing returns rapidly. However, you may also see substantial disruptions and bugs.

Big bang rollouts are best for when you have limited exposure. When only one or two functional teams will use the software internally, you can conduct big bang rollouts far more comfortably. However, no matter what, it’s essential to always have a contingency plan in case the system crashes or otherwise fails.

Parallel Rollouts

In the parallel rollout method, both the new system and the legacy system are run simultaneously, or in parallel. Doing this provides a “safety net” of sorts, giving your team the opportunity to learn the new tool at their own pace, without losing access to the old system they’re accustomed to.

This rollout is slower than a big bang rollout, but faster than a phased rollout. Additionally, it provides the lowest level of risk since you still have access to the legacy system users are familiar with. However, there are many cons to be aware of. Parallel rollouts are costly as it’s expensive to maintain both systems. Additionally, it can be challenging to drive adoption of the new tool when your team can still access the old system they already know how to use. Most importantly, when you’re using two systems, your team has to input data into both, otherwise there will be missing information in your system. This can be confusing and difficult to maintain.

Phased Rollouts

Phased rollouts consist of releasing a feature to segments of your user base instead of everyone at once. This provides ample time for testing in a real-world environment without the risk of moving your entire userbase over at once. While phased rollouts take longer than other methods, they provide the least amount of risk since only a segment of your users is exposed at a time and you can roll back updates if anything goes wrong.

There are a few common strategies for phased rollouts. The most common involves first releasing to the team that built the feature, then the full internal team, then a beta list, then the rest of the userbase. You can also define a group of friendly beta users to be your early testers. By rolling out the new feature to an internal team or group of beta testers, you’re able to identify bugs or other errors that may not be evident in preliminary testing.

What are the benefits of phased rollouts?

Phased rollouts are essential for developers today. They allow developers to release on their schedule while testing in production and enabling continuous delivery. Even though the deployment method can take longer, the benefits far outweigh this concern.

Release at Your Pace

Some features necessitate additional capacity, either in hardware, software, or support. Phased rollouts let you scale at a pace that’s comfortable for you and your team.

Test in Production

Software bugs or application issues can leave users with a negative experience. By releasing to a small percentage of your users and slowly increasing that percentage, you can test code in production and see that a feature is working properly before fully releasing it.

This strategy is called Canary Deployment. Like a canary in a coal mine, phased deployment allows you to expose a low-risk audience to determine if it’s safe to proceed. If an error presents itself, you can easily walk the update back to resolve the issue before rolling it out further.

Another benefit of phased rollouts is that your developers are forced to test on a consistent basis. When testing is built right into your feature rollout strategy, you can’t skip over that crucial step in the process.

Understand the User Experience

With phased rollouts, you’re able to take a closer look at how different segments of your users interact with your application and the features within it. With each new segment you release to, it’s essential to monitor key metrics and determine your users’ experiences. 

Not only does this help you ensure a successful rollout with this feature, but understanding the user experience will help you plan additional features to roll out in the future.

More Accurate Planning

By rolling out a new feature in phases, you’re able to more accurately plan from a business perspective. For example, after rolling out to your first user segment, you’ll have a better idea of capacity and bandwidth requirements of your new feature. That way, you’re able to ensure your hardware is ready to support rolling out to the rest of your users.

Additionally, through phased rollouts, you’re able to monitor support requests more easily as only a subset of users will be exposed to the feature at a time. This makes it easier on your customer support team and can ensure you’re prepared to handle incoming requests and questions as you open features up to your broader user base.

Enable Continuous Delivery

Continuous delivery is a strategy of rapid testing and deployment that involves small updates executed regularly. Continuous delivery enables faster growth by reducing barriers and minimizing risk.

What are best practices for phased rollouts?

For many organizations, phased rollouts are best for deploying application updates. In order to see the aforementioned benefits and avoid potential concerns, keep these best practices in mind.

Determine Your Deployment Path

Know in advance how you plan to deploy your feature flags. Typically, it’s a good idea to start with the internal team working on the feature, then roll out to the rest of your team after that. Once your entire internal team has confirmed the feature has no issues, you can begin rolling out to your beta testers, then early adopters, and finally the rest of your users.

Simplify Your User Segments

It’s important to not get overly complex with segmenting your user groups. Keep things simple when you’re starting out to avoid confusion and ensure optimal results. This will also make it easier to analyze feature performance.

Make Small Adjustments

Don’t make enormous application changes in your feature flags. Ensure updates are worth your team’s effort, but not so substantial they entirely alter how your application is used.

Ensure You Have Enough Traffic

In order to fully experience the value of phased rollouts, you need to get substantial traffic through the feature. Your segment size and userbase percentage will depend on how much volume your application sees. For A/B testing, you’ll need enough traffic to determine statistical significance. When testing an API, you need enough traffic to see that it scales properly. If you don’t have enough traffic, you can establish beta customers and use qualitative feedback through surveys and interviews.

Track Key Metrics

As you roll out new features, track key user metrics such as engagement, time spent in the application, and bounce rate. Be sure to track metrics specific to the new feature as well. You should always have baseline metrics from before you rolled out an update that you can use for comparison purposes.

Consider the Impact of Different App Experiences

Be wary of issues that may arise when different users have different experiences. Specifically, this can cause confusion for users discussing their experience as well as your support team. It’s a good idea to keep your audience in mind when phasing in new updates and don’t overhaul your entire application for one public segment and not another.

Enable phased rollouts with Flagsmith.

You can use Flagsmith to define your user segments and control features against those segments. Flagsmith integrates with your existing tech stack, making it easy to analyze the performance of new features you roll out. Revamp your phased deployment strategy with Flagsmith — get started for free.