Feature Flag for production deploy
Feature flags allow developers to turn certain functionality on and off during runtime, without deploying new code. The idea behind feature flags is to build conditional feature branches into code in order to make logic available only to certain groups of users at a time. If the flag is “on,” a new code is executed, if the flag is “off,” the code is skipped.
Pros of using Feature Flags
- Safely test features in production in private with a selected group of users. Easily add or remove users who can use that feature.
- Deploy code when you want and independently release — and unreleased — features with the flip of a switch
- Get real-time visibility into the impact that every new change is having
- Control and cater to each individual’s experience with user segmentation
- Make changes to live features without having to redeploy or require app-store updates
- Gather Live Feedback Before You Release
Read about how Google Chrome, Spotify, and Instagram use feature flags to test rollouts and new features in a risk-free way!
How do Feature Flags work?
Feature Flags are also known as Feature switch, feature toggle, Feature Bits, or Feature Flippers. These are all synonyms for the same set of techniques.
You start by specifying an audience segmentation; this is where you pick who is going to see the new feature.
Next, you set the distribution and choose what percentage of the selected users will be initially included in the rollout. You also have the option to set a timed rollout schedule, whereby you can control a release as you increase or decrease the number of users in it.
Create the feature flag. Use them with ‘if-condition’ for the code you want to roll out.
In my project team, we use Flagr tool to enable or disable features during execution time without any deployment. It’s a powerful tool that allows feature flags, experimentation (A/B testing), and dynamic configuration.
Picture the scene. You’re one member of several teams. You are working on adding new conditions to the legacy code. The API hit is 13 billion users per month. The task is in the backend that adds campaigns and maintaining sub-campaigns for the corresponding campaigns in the ‘campaign’ and ‘campaignGroup’ collections. The code function has 1500 plus lines. In this work of other, you need to adjust new feature inside the same API service. Your boss want’s to test if this newly added logic is viable for some users to take feedback from certain users before the overall release. Feature flags to the rescue!
const featureFlagEnabled =
await services.featureFlags.get({account: account});if(featureFlagEnabled){
//perform this logic
}
Scenarios where feature flags come super handy:
- An essential feature needs to go into production, and you need to test it in production. It can’t be released to everyone unless everything is fine like a logic change inside the above scenario.
- It is often impossible to completely simulate the production environment in staging, feature toggles allow you to validate the functionality of new feature releases in the real world while minimizing the risk. Feature flags also encourage trunk-based development, which helps prevent merge conflicts from divergent code paths.
- You want to deploy a big feature in steps and until the last step is done the feature is not complete.
- You want your changes pushed to production and merged with the main branch. But the new changes are not public yet.
- You don’t want to spend hours fighting merge conflicts. You are working on it for days and your code has not been merged to the main branch.
- You want to schedule a feature in the future, you could have a feature switch based on date or time.
Keynotes
Deploy the feature as ‘off’ in production and then implement your release and rollout strategy. This could be an incremental percentage rollout, individual user targeting, or targeting groups of users¹.
Apply feature switch and deploy small things. Test them on production without anyone noticing! Thank you for reading.
Reference:
1. hackernoon|Feature Flag-Driven Releases by Justin Baker, Design Lead, Growth at Atlassian.