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 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 TrunkBasedDevelopment.com.
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.