As a digital marketer, I wind up writing a decent number of articles for clients’ blogs. And as always happens when writing about a topic, I’ve learned a decent amount about these clients’ products. Our current biggest writing-focused client is Split, which is a B2B SaaS company selling feature flags as a service. But hold up, what on earth are feature flags? Well, I’m about to tell you.
A feature flag is a piece of conditional code that you wrap around any new feature, which links that feature to a dashboard. From this dashboard you can turn off the feature, release it to only a subset of your userbase, and generally manage all your features so you can see which ones are in use.
Now, how exactly is this useful? To start with, imagine a pre-existing codebase for a currently-working app. You don’t always start with this—one of the ways to implement continuous deployment is to start with a blank canvas—but this is usually how it works and is one of the most common feature flag use cases. Now, imagine a dev team working on a new feature to add to that app.
Without feature flags, this looks like a number of things, all of which are sub-optimal. You end up releasing only a few times a year because you need to do endless testing to make sure things aren’t broken before you push to production. You get crazy long-lived feature branches that take forever to merge back to trunk (“master” in Github terminology) and make a huge mess when they finally do. Or, worst, you accidentally break something but don’t realize until after you’ve already pushed to production, and you have to do a painful rollback to the previous version to fix the bugs, then re-release afterwards, and deal with the fallout from
With feature flags, the scenario looks much better. Instead of testing with your staff before pushing to production, just test in production on your real users—starting with just a select few of them, who have perhaps opted in to be guinea pigs. Instead of making branches which may or may not outlive their welcome and/or create a merge hell when you try to get them back to trunk, you can do everything straight in trunk. And if you break something anywhere in this process, you can just turn the feature off, no rollback required.
Beyond simply making development less of a headache overall, there are some specific things you can do with feature flags that are much harder otherwise. Some notable examples include continuous integration/delivery/deployment, canary releases and phased rollouts, and dark launches.
Continuous integration is the process of constantly and deliberately merging every code change to trunk (/master). Continuous delivery is constantly pushing each change to a production-like environment where there’s only one step of manual testing before it goes to end users. Continuous deployment is similar to continuous delivery, but without the manual testing: automated testing is the only step between the code deployment and the end users.
Canary releases and phased rollouts are similar in that they both involve releasing new features to only a subset of the userbase at first. With a canary release, the userbase subset is chosen and targeted to be test subjects, and they act like a canary in a coal mine, letting developers know whether the feature is safe to release to the broader public. With a phased rollout, you begin with a subset, which you then slowly ramp up until you’ve released to your entire userbase.
Dark launching is, literally, the process of launching a feature while keeping your users in the dark. Specifically, you use all the portions of your real infrastructure that would ordinarily be used in serving the feature, but you don’t actually show it to users. Feature flags can make this happen by letting you restrict access to only internal users, which lets the developers activate the feature in absence of a real code deployment.
There are a bunch more uses for feature flags – some of which are detailed on Split’s or FeatureFlags’s use cases pages, others can be found on Martin Fowler’s blog.