If you do:<p>- What feature flag tool do you use?
- Do you like the experience? (Could the experience be better? How?)<p>If you don’t:<p>- Do you want to? (What’s stopping you?)
- or do you not want to? (What puts you off?)
I have a directory of feature flags IN THE REPO that look like this:<p><pre><code> $ cat default/setting/html/avatar_link_to_person_when_approved
0
</code></pre>
I then have a directory of local config (NOT in the repo) that look like this:<p><pre><code> $ cat config/setting/html/avatar_link_to_person_when_approved
1
</code></pre>
Then my feature flag code looks like this:<p><pre><code> if (GetConfig('setting/html/avatar_link_to_person_when_approved')) {
# do some stuff
}
</code></pre>
Later on, when the feature is stable, and if it makes sense to make it a default feature, I can change the default without affecting existing installations.<p>The "feature flag tool" I use is a procedure called GetConfig() which is ~250 lines of code with comments and logic for overlays.<p>Please let me know if you have any questions about this method.
Its a SaaS web app so feature flags are stored in the DB for easing flipping by biz people so they can rollout features w/o having to involve engineers. Simple homegrown solution of a table, name of feature flag and a boolean, corresponding object with handy methods and a simple UI. Feature flags are commits as blocks of feature flagged code. There might be a dozen or two at a time so querying an indexed DB table with < 50 rows is not an issue.<p>Blocks of code around the intended feature flag find the feature flag boolean and do whatever they are supposed to do. If a feature flag is not found it defaults to false/off. Later on after features are rolled out and have become the default, an engineer removes the FF code, related tests, and DB row.<p>I don't see how a tool/SaaS could be any better for this scenario. There is a DB dependency but honestly if the DB isn't available then shit is on fire in a very bad way and I don't care about feature flags in that moment.<p>Other options could be ENV variables loaded at app startup, this can get unwieldly though if you have a lot of them and requires an engineer to be involved. Putting feature flags in an external system seems like purposely introducing more failure modes to your app.
> do you commit feature flags<p>It doesn’t really matter how you manage changes to feature flags, but using version control gives you a couple of nice benefits:<p>* gives developers the opportunity to describe their change<p>* let’s you roll back a problematic patch<p>* blame and bisect problematic patches<p>Ideally, you should also be able to see your feature flag changes in prod much faster than it takes to cut a release. You need this in order to be able to quickly roll back bad features.<p>> What feature flag tool do you use?<p>See <a href="https://engineering.fb.com/2017/08/31/web/rapid-release-at-massive-scale/" rel="nofollow noreferrer">https://engineering.fb.com/2017/08/31/web/rapid-release-at-m...</a>
Yes, for our mobile app we implemented feature flags to avoid the problem of having large branches that could not be merged until they were ready for production.<p>We used a simple approach without any extra tools: the feature flags were constants that controlled whether certain code blocks were active in dev, test, or prod environments.<p>This enabled us to merge and test work in progress branches regularly before they shipped in the production app. It also made code reviews more frequent and easier.
Yes, we commit the default state (normally off but sometimes on if we are planning to turn something existing off later) then use Salt to push out flags to different boxes so we can canary the changes a few places before taking it global.<p>Eventually once something is fully rolled out we might go back and change the default state but since Salt is always going to manage most of that it’s not a high priority.