Bookout

K's choice for FE development

General Somehow I lead 

Feature flags (Feature Toggle)

krakover.ariel , , ,

On the continues mission to improve the way my team and I work, came the part I introduced them with the concept of a feature flag. It came up once one of the team members completed a small task, and got a comment to remember not to upload until all the other parts are in place.

“No”, I commented back, “Upload it now with a feature flag”, I wrote.

“Whats a feature flag?” he asked. So this is my answer.

Deploy When You Want, Release When You’re Ready

A feature flag is not only an on/off boolean value, but a development mindset that aims to capsulate each feature under a defined section, gated by a flag. We all use it with the “isSignedin / isPremium / isAdmin” flags. But it can do much more. We use this strategy so the app will contain two different behaviors at the same time: sometimes active simultaneously, to different audiences, sometimes waiting for the moment it will wake from the ashes of the וnaccessible code.

Feature Toggles are also referred to as Feature Flags, Feature Bits, or Feature Flippers. These are all synonyms for the same set of techniques. Throughout this article, I’ll use feature toggles and feature flags interchangeably.

Pete Hodgson on Feature Toggles (aka Feature Flags)

Who needs it

Feature flag mindset aims to provide plenty of different needs:

CI/CD – Branching: Feature flags allow the developer to upload the feature before time, merging and deploying to production. This prevents the creation of big branches, with a huge amount of code. And this can provide a major step towards CI/CD since it’s possible to release tasks before all it’s necessary components are ready. And to rack the limiting connection between deploy & release dates.

Production test: With the ability to activate a feature to a very targeted audience, comes the option to turn it on for QA needs, on the production environment. Playing with it live before opening it to the rest of the world.

Product & Marketing Driven Releases: Once the code is on production, waiting for the flag to change, marketing has the ability to schedule the release of the feature without the deployment process.

Kill Switch / Rollout: Unfortunately, sometimes there is a need for a rollback. With a feature flag, both the old code and the new are still on production. So it’s very easy to turn the feature off or roll it out smoothly.

User Targeting: Since the feature flag can be based on dynamic data, it’s very easy to target only specific types of users to use the new feature. This ability has many applications:

  • User Targeting: Open the feature to a specific type of user: by a campaign, country, browser type, or any other available information.
  • Samples: Expose the feature to a small number of users, feeling, and testing the impact of it with fewer risks.
  • Beta Testing: Allows to expose the feature to a well-defined beta user group.
  • A/B Testing: Since it’s easy to have multiple different behaviors at the same time, it’s very easy to create and manage A/B tests.

Types of feature flags

As seen, there are many uses to feature flags, so there they have different types of flags:

Release toggles: Use to upload a hidden new feature to production, and activate it later on. This flag supposed to have. a short lifespan, and would be removed once the feature had been released.

Operational toggles: Use to maintain hidden operation, like manage the data migration by volume, controls different flows of algorithms, or control the distribution on users.

Experimental Toggles: Use to activate a different behavior for a beta group, or for A/B testings.

Permission Toggles: Use to create a different flow for different types of users. Like admin capabilities, country resurrections and so.

Assimilation

Hard-coded constants: Storing the value in the code, as a variable. Like const values.

Config files: Gathering the flags in one well-defined place.

Database configs: A convenient place to store keys, that provide the option to update the value of the key without the deployment process.

Open Source Libraries: like Flipper, Unleash, and plenty of others out there.

Third-Party Service: If needed there are very strong and rich tools that can: Provide statistics, dynamic control, scheduled changes, complicated algorithm to define the key-values, easy targeting UX, and more. 

So to avoid feature flag hell, create them only when it makes sense, clean them up after you are done, and always check if it makes sense to re-use flags before creating your own.

Tim Hysniu on Coding with Feature Flags: How-to Guide and Best Practices

Principles…

Naming convention: As written above, about the different types of feature flags. Their name should express the type, the usage. It must be easy to connect between the flag and its usage. If it’s a short living flag like a release toggle, it must be clear that it’s a temporary toggle, so it will not stay there forever.

Encapsulation of code: As expressed above, more than keeping a list of booleans, feature flags are about encapsulating features and logic in the code. If can be done by executing different access-point to the feature, or better by using some injection method.

Change is a deploy: Since changing the flag activates a dormant section of code, it must be handled as any code release. With all the caution and awareness involved.

Online playground: Having some admin UI that allows us to see all the active keys is nice, but the ability to change them for the specific developer/QA is something that provides a sense of security and control. Allows rechecking moments before release.

Simple to use: There is nothing that provides more sense of control to the developer than the simplicity of if(isTheFeatureOn). KISS!

Sophisticated tools: On the other hand, if there is a need, don’t reinvent the wheel. There are plenty of reliable solutions and third-party Service to handle sophisticated needs.

Short-living: Most of the feature flags meant to have a short life. Keeping them means that the code carries unused sections. The best practice is to open a ticking to remove the flag at the moment you create it. This way it won’t be forgotten.

Small in number: The more keys, the more chance for problems, the less control, and everything written on the short-living sections.

Removal: Once removing the key, it’s important to easily identify the section of code that can be removed with it. One of the developer’s biggest fears is seeing code without the ability to understand it’s context. So dead code might stay forever.

Conclusion

While presenting this one of the team members claimed: “But in many cases, this can not work”.

“You are right”, I replied, “But sometimes it can”.

Thanks to