Enter your email and we will send you a password immediately
If Alex has provided you with a password, enter it here
As the number of development teams grows and system complexity increases we have to find ways to ship features to customers continuously as well as protect customers from outages of 3rd party APIs. To solve this problem we can use "feature flags" technique. In this post we share opinionated guidelines and and best practices for working with Feature Flags.
Feature Flags help teams target specific customer by enabling or disabling specific "code paths" or in the solution they are developing.
New approach allows for testing new features on a subset of loyal customers. No matter how much testing you do in lower environments, something unexpected usually comes up in production which you can’t prepare for due to volume issue, edge cases or environment issues so feature flags help a lot.
We identified 2 types of feature flags:
Allows you to turn things on an off in a running application, these flags are the most useful, because you can enable features at will. For example if you worked 6 weeks on a feature, to not do a big-bang roll out you can enable the feature for test users and then depending on your rollout plan for everyone else.
Enables or includes features into artifact based on a build process. For example if you have multiple payment providers, and you want to disable one and exclude it from the build - you would use build time FF.
We separate feature flags by function they perform:
🏎 "Launch" feature flags
Temporary FFs that are created before feature is completed to enable continuous deploy of the app and enable feature for test users. Also to perform gradual rollout to customers based on their segment. These are usually deleted when feature is fully completed and deployed to customers.
Lifecycle of launch feature flags:
🚩 Risk-mitigation flags
These flags are long-lived, they are created and kept permanently. It is useful to turn on and off certain features of the application when necessary.
Few use cases:
We recommend to establish straightforward guidelines for mananging features flags so they dont get out of control as you scale.
Guidelines include naming conventions, lifecycle of feature flags, etc:
enable_paypal?is a good name, because it is clear if feature flag is enabled, PayPal will be enabled too 😄.
disable_paypal?is bad, because for developers it takes more time to process negative statements (we tested this!).
Prior to introduction of feature flags the alternative was to time releases to feature launches which turned out to be super stressful and fragile as it didn’t allow to test new features in production prior to customer launch to ensure quality.