"Feature Flags" is a standard way to perform A/B testing of features assigned to some portion of users. That's precisely what split.io is providing.
It's called a controlled feature rollout, it's a common way of testing new features with a small subset of the users before updating the version everyone gets. This will happen for everyone if nobody speaks up against it, which is why I made this post. Hopefully if enough like minded people signal boost this, they will understand how important it is and will let it be.
And their support resources are bullshit, part of what made this so confusing is that nothing on their website pertained to the build I had.
Well, this is the kind of answer I was looking for though. I have never heard of feature flags as a practice before (I work for an enterprise company, I am out of the loop on a lot of things)
This is definitely what I mean, but I was hoping there was some more figured out parts using them. They seem pretty straightforward for creating multiple versions of an application at compile time, but still you would have to build a pretty complicated CI system to distribute apps with different features to different users, like if it is a web app that is supposed to be different based on user permissions. A quick search shows that there are definitely service products that are supposed do what I am talking about.
I mean, heck, what do you use to manage your feature flags? Or is it just something that you implement in your codebase...
Personally I don't use any go specific library, leveraging redis/etcd to store feature flags that can be changed on the fly. If it's static, using a combination of environment variable and config file is good enough.
I was interested in unleash and split.io before when I wanted to check out feature flag management that is more full featured (e.g. for A/B testing), but ended up not using them for various reasons.
Purely you say? I highly disagree.
Applications like Facebook have billions of <u>active</u> users and as a result run many experiments on their users, from changing subtle UI components to testing fully blown features (like the marketplace for example). They have thousands of engineers working on the product all at once. It's enough to make someone dizzy.
The reality is that mobile applications are becoming more complicated than most of us would like to think. Mobile apps are priority #1 to the majority of the large tech companies in the industry (FB, Instagram, Uber, etc). The way we ship software has changed dramatically in the last decade.