Does anyone know the best ways/practices to implement feature flagging (with kill switch, opt-in, incremental roll outs etc…) with Meteor? According to this LaunchDarkly page:
Feature flags give a software organization the power to reduce risk, iterate quicker, and get more control.
So today, we wanted to make some features (payment management, feature-testing) to be available to a subset of users geographically. I know companies like Facebook, Apple, Twitter and Uber have all implemented feature flagging into their own architectures at different layers. Though allowing users access a separate deployment (in beta) could do the trick, but it’s not really flexible. I am also wondering with the recent implementation of dynamic imports in Meteor and component nature of view layers, feature flagging should be easy.
Feature flagging is a method by which developers wrap a new feature in an if/then statement to gain more control over its release. By wrapping a feature with a flag, it’s possible to isolate its effect on the system and to turn that flag on or off independent from a deployment. This effectively separates feature rollout from code deployment. Feature flagging is a core component of continuous delivery that empowers software organizations to release quickly and reliably.
If you have done this in your app, I would like to know the different ways to achieve this. Was it done geographically at the network layer (using a CDN like Cloudflare etc.) or at the view layer?
Thanks
2 Likes
Feature flagging is sort of an odd name for this.
Configuration switches, switches, or toggles is appropriate. Flagging is for calling attention to things like spam comments or abusive videos. Essentially all of these are idiomatic names which imply an action based on a boolean value, but flagging brings along extra baggage, ie; something which requires extra attention - a condition normally false is now positive and should be inspected. Whereas ‘switch’ and ‘toggle’ are things you turn on and off as part of their basic function and it is assumed that they are used often, as opposed to a flag which is only raised under special conditions.
You then go on to ask if anyone is doing this at a geographical level, ie; making this decision for the user. In which case the boolean is neither a flag, switch or toggle but a determinant as the user has no decision to make.
If you are actually trying to offer a user some sort of choice which will affect their environment in some way, then you probably are looking for a feature toggle. If you want to allow the admin some setting which enables or disables features system-wide, you want a configuration switch.
Anywho, that was the long of it… the short of it is, yes, you can use true|false, 0|1, null|!null values to enable this sort of thing in your code.
The article has nice graphics, but the content is pretty meh.
Of course, I think the whole point of your effort to understand the construction, usage and implementation of booleans and if/then statements would be moot if your if statement had a bug.
1 Like
Thanks for taking the time to explain.
:> I think for your purposes, you might want to base it on environment variables. Then you could say, turn the feature on in staging but off in production using a simple if statement on the value of the variable. Then simply flip the value in production when you were ready to roll it out and eliminate the loop when satisfied. This would prevent having to write some admin-level configuration UI.
Of course, if you wanted the user to be able to opt-in or out of said feature… it might be better to keep a collection of opt-in users or set an opt-in flag 
on the user record which would enable you to provide them a toggle to turn their opt-in status on or off.
1 Like
Perfectus! Exactly what we needed. Thanks again.
You’re welcome… I can be helpful as well as snarky sometimes 
1 Like