Today, we are inviting Edith Harbaugh from LaunchDarkly as a guest writer for the ALM Blog to talk a little bit about the different patterns of Feature Flag implementations which has been a common topic I get asked about from many of you. If you didn’t see it, Edith joined us on stage at Build 2016 earlier this year to launch a new marketplace extension of their feature flags service with Visual Studio Team Services.
Product Manager, Visual Studio Team Services
A question I get asked is “Are feature flags better for risk mitigation, fast feedback, hypothesis-driven development or long term control?” My answer is “Yes!” There’s no one right way to use feature flags, they’re a valuable technique to power more effective DevOps. I’ll walk through how you can use feature flags to speed up, derisk, and improve your development.
A feature flag is a conditional in your code, an If then for two different options. At its simplest, a feature flag can be used to flag a new or risky behavior. First, the feature is deployed “off”. Then, separate from deployment, you can turn on the new feature. If the feature doesn’t behave as expected, it’s possible to shut it off quickly. This is better than rolling back an entire version because you’ve isolated the change. In addition, it allows development on other features to continue without forcing a complete rollback. In effect, you’re isolating the change while your code base evolves around it. Risk is uncertainty of unknown issues. With feature flagging, you’re mitigating risk by making every feature encapsulated and controlled.
Beta Feedback and Feature Targeting
For faster feedback, beyond an on/off switch, you can control at a very granular level who sees the new feature. You can choose VIPs, early beta users, or regions of the country. This technique is known as canary launches or dark launches. Instead of having “one size fits all” releases, you can iterate with some users to quickly get their feedback. You can also block users who are known to be picky or want only the stablest versions. Microsoft has been using these techniques (canary launches, dark launches for decades in their own releases. For example, Microsoft gives early access to Microsoft MVP awardees to get feedback on new features that are being built.
Once a feature is cleanly encapsulated, it can be used for hypothesis-driven development, as Microsoft’s Yammer does. Want to know whether a feature helped with engagement or lifted revenue? Feature flags allow you to tie back real metrics to code. After knowing the impact of your feature, you can switch the feature on (or off) for all users.
Feature flags are also good for long-term access level control. If you have a feature that only advanced users should access, you can use a feature to have a different experience for “newbie” vs “power users”. You can use feature flags to control localization, or you can also block an entire country if a feature shouldn’t be available there.
Subscription Plans and SKU Management
You can bundle several flags together to form a subscription. You can have a silver, platinum, and gold tier. You can build one-off tiers for users. LaunchDarkly does this ourselves to enable custom contracts.
Now, with the Visual Studio Team Services LaunchDarkly extension, it’s easier than ever to fit feature flags into your releases. From Visual Studio Team Services, you can tie flags per environment into your release. You’re in complete control of your releases and functionality.