Think of it as being exactly the same problem as "different customers have paid for different features". It's just that only the internal tester customer has paid for this new feature, so far.
How do you handle that? You need a consistent permissions framework.
Re:You Can’t Have a Rollback Button
by daddykotex on Monday March 06, 2017 @10:41AM
(#13803358)
The thing is that in my experience, features behind flags, are not always a per customer artifact.
Or maybe they should be and out implementation of feature flags should always take the current customer into consideration...
There are practices which can ease the use of feature flags. E.g.
- Only a handful feature flags at a time.
- When the feature is stable, delete from everywhere!
- Easily turn on and off.
- No branching makes it much easier.
Re:You Can’t Have a Rollback Button
by daddykotex on Monday March 06, 2017 @10:33AM
(#13803297)
How do you avoid branching?
I believe LaunchDarkly (https://launchdarkly.com/) is trying to solve that. Still seems like a strange problem to apply a catch-all solution too however.
In my experience, it's relatively easy and clean to work with `if(feature) this else that` in a simple backend application (a service that pulls from a queue and maintain a state, for example).
The problem arise when you start working with more complex applications. Specifically application with complex UI where you have to check the state of the flag at multiple different places in the code. You end up adding branches all over the code, branches that will be removed once the feature is fully deployed and known to be correct.
It adds a lot of overhead, the code is less readable.
There must be a way to do implement feature flags in a smoother way.