From c6d9e08b756ae9eef8c0f4f7ba9a2eff999adefc Mon Sep 17 00:00:00 2001 From: Charles-Axel Dein Date: Fri, 20 Nov 2015 12:00:59 -0800 Subject: [PATCH] Improve feature flags --- feature-flags.md | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/feature-flags.md b/feature-flags.md index 06d3fb3..c660b24 100644 --- a/feature-flags.md +++ b/feature-flags.md @@ -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 ----------