Common Use Cases

Using feature flags has helped simplify engineering practices, canary release, experiments and more.

Teams have been using feature flags for targeted releases, experiments through A/B testing, or mitigating risk but it does not end there. Companies like Google and Facebook make use of feature flags in their standard engineering practices.

Canary Releases

Canary releasing is a technique that is used to roll out a feature slowly. It starts with releasing the feature to a small subset of users and slowly ramping up the percentage of users.

During the release teams will make use of some kind of monitoring solution to see how well the new feature is performing for users who have it turned on. Once teams are happy with how the feature is performing they can now ramp up percentage.

The length of canary release can vary and this depends heavily on what type of feature is being released. In most cases the the release process is short where critical metrics that teams are looking for are error rate or performance metrics. Once teams are happy with the results the percentage is ramped up to 100% and the old path is ready to sunset.

Regional Releases

Unlike canary releases, regional releases focus on users of a particular regions first before rolling it out to all users. A typical scenario can be rolling out features to one region first in order to get validation about the feature being released.

For anonymous users who are just passing by but did not register to any of your products yet, it is still possible to identify their location by using their IP address.

Regional releases can be done in combination with canary releases so teams can mitigate risk even if releasing to one region only.

Targeted Releases and Beta Testing

This is one of the most frequent use cases when using a feature flagging service. Product teams may already have a list of beta users or early adopters of your feature who have opted in. These are already registered users who we can identify usually by a user ID or a combination of attributes that already persist. ProbeBeta™ allows teams to roll out features only to this segment of users before rolling it out to all users.

Targeted releases, just like with any other type of release, can be done in conjunction with canary releases. Depending on the size of the beta users set you can start with a subset of beta segment and slowly ramp it up to all beta users.

Experiments and Multivariate Probes

Teams might be interested to do user testing on a feature before rolling it out to all users. For example, you might be interested to test several colors for a button and measure click through rate for each color. ProbeBeta™ allows you to create multiple options that are consistently served to anonymous or registered users.

While traditional A/B testing is very much possible, ProbeBeta™ also allows multivariate probes with more than two options. This means that you can split traffic more than 2 ways and measure several possibilies with a single probe.

Once you get a reasonable sample size you are able to make educated guesses about which options will convert best for your feature that you are releasing or planning to modify.

Roll-outs and Deployment Decoupled

While on advantage of feature flag services is ability to dynamically update feature status there are many other engineering benefits that many tech giants are now embracing.

First, ability for engineers to deploy at will without having to worry about schedules when a feature should be available to production is tremendously valuable. Engineers can now focus on what they do best while product managers handle roll-outs and schedules.

But there are other engineering benefits as well. Trunk-based development has become increasingly popular and many high progile companies like Google, Facebook and Amazon. As teams grow branching and merging complexity also increases. Instead of having developers spend time with branching, merging and releasing they can focus on what they do best, write quality and clean code. The idea is that the entire team should be using the same main branch, called trunk or master. Releases are handled separately by a release engineer where developers do not check in code. trunk based development using a shared branch

Trunk-based development eliminates the need for feature branches, bugfix branches and parallel release branches. Instead, everyone commits to one main branch called trunk. Developers commit to main branch where all features are hidden behind a feature toggle until the feature is ready to be released. For more info check

Production Testing and Risk Mitigation

Uses cases mentioned so far may be solving different problems, but they all share one common benefit. Ability to turn features on an off dynamically and to quickly shut them off is reason enough to want to use feature flagging third-party services.

This may not necessarily seem useful in applications that are not receiving much traffic or do not have mission-critical features since some downtime may be tolerable. In many cases, having a proprietary solutions or even static toggles that you store in a config file may be sufficient. As applications get larger the need for having a mechanism to have dynamic control over features becomes more apparent.

We'll never share your phone with anyone else.
We'll never share your email with anyone else.
We'd love to know more about your role is in your company.
What is the use case that best describes your needs?
We're interested to know what your use cases and type of users you are working with.

By submitting this form you agree with our privacy policy and to receive marketing emails from ProbeBeta™. You may unsubscribe from these emails at any time.