Improve feature flags

This commit is contained in:
Charles-Axel Dein 2015-11-20 12:00:59 -08:00
parent b288dd90d7
commit c6d9e08b75
1 changed files with 25 additions and 1 deletions

View File

@ -17,7 +17,31 @@ Why use feature flags?
failure.
* **Gradual rollout**: feature flags enable gradual rollout, where a piece of
code is gradually activated, for instance on a per city basis, or on a per
user group basis. This builds confidence in the feature release process.
user group basis. This builds confidence in the feature release process, and
allows the engineer to verify that the new implementation is actually better
(for instance, when coupled with A/B testing frameworks).
Should feature flags be used for everything?
--------------------------------------------
I don't think so. I think it's a matter of good judgment. Just like 100% test
coverage does not always make sense (provided lines that are not tested are
explicitly ignored), adding or not adding a feature flag is an engineering
decision.
When would I not use a feature flag?
* Simple changes: copy, logging, etc.
* When rolling back takes a few seconds
* Feature that is used only in asynchronous jobs that are safe to retry and
don't impact the user experience.
When should a feature flag be used?
* Large refactors
* Changing integration points
* Performance optimization
* New flows
References
----------