Feature Flags at Flite
Feature flags (or flippers or toggles or whatever you like to call them) are a really important piece to any development process, especially if you are employing Continuous Integration (CI) . Even if you’re not quite there with CI, feature flags can still be a very useful tool that can help agile development teams be more productive, produce higher quality products, and work at the speed of business.
Traditionally, feature flags are something that engineering teams control, probably for good reasons, because you can potentially end up opening the flood gates and may need to flip things back quickly when things go awry. When we are talking about things like switching from using 3rd party API A to 3rd party API B, turning on a new server health monitoring system, or using a new optimization algorithm, engineering should most definitely be at the controls. However, if we really think about it, feature flags (if they truly controlled “features”) should be in the hands of capable Product Managers or Account Managers. And if we take the concept further, we need to go beyond the basic on/off, true/false nature of flags and get into the world of more sophisticated deployment strategies.
There are plenty of great examples out there when it comes to taking the original, plain-vanilla on/off feature flag to the next level. One notable example is the way Facebook did their new “timeline” feature rollout. But the idea of being able to control a feature by exposing it to n-percent of a user base, segment of the user base, specific set of users, etc has probably been around for ages. Being able to work the different dials and levers for a feature is something all Product Managers need. Then providing them with the feedback in the form of real metrics and measurement to indicate whether features are effective and useful completes the loop. It’s really a no-brainer, especially for agile companies who have that “lean startup” mentality.
Wow, sounds great right? But also a lot more complicated and a lot more work than the simple on/off switch we first started with. The good news is you don’t have to build all of this stuff yourself anymore. As we all well know if it’s a great idea, someone out there has probably thought of a way to make it easy for you. We at Flite are fortunate to have bumped into LaunchDarkly, a service that gives you a powerful way to take control of how features are released to your customers. Like many startups or even non-startups, we have our own home-grown system for controlling features. It is very similar to how many experts in the field describe implementing feature flags using config files and the like. Basically, it’s something you can flip on/off while code is in production and does not require new code to be deployed or servers to be restarted. But with LaunchDarkly, you can literally get all of that and more without having to burden your existing code base with feature flag specific stuff that isn’t core to your actual product or service.
With LaunchDarkly, Flite can give access to a specific feature by simply moving a slider on a zero to 100% scale or flipping a toggle. We can also specify custom rules to never include or always include a specific group of users by defining a special property. The flexibility of building custom rules is paramount when it comes to slicing up your user base so that you can do “smart-rollouts” of features or do “dark-launches” (controlled live testing on production) with a limited set of internal users. The LaunchDarkly UI is a clean and simple dashboard that empowers Product Managers to quickly scan the available features, see what’s been released and how, and make business decisions regarding the features they own. There is no need to get engineering involved!
Flite has already gone live with LaunchDarkly and we are currently exploring how we can use it further. It is really easy to get started with it and I’ll be very excited when the metrics piece of the LaunchDarkly offering is available!