Improve feature flags
This commit is contained in:
parent
b288dd90d7
commit
c6d9e08b75
@ -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
|
||||
----------
|
||||
|
Loading…
Reference in New Issue
Block a user