Ask HN: Do you commit feature flags to Git?

[GeorgeMac]

If you do:

- What feature flag tool do you use? - Do you like the experience? (Could the experience be better? How?)

If you don’t:

- Do you want to? (What’s stopping you?) - or do you not want to? (What puts you off?)

[forgotmypw17]

I have a directory of feature flags IN THE REPO that look like this:

    $ cat default/setting/html/avatar_link_to_person_when_approved
    0

I then have a directory of local config (NOT in the repo) that look like this:

    $ cat config/setting/html/avatar_link_to_person_when_approved
    1

Then my feature flag code looks like this:

    if (GetConfig('setting/html/avatar_link_to_person_when_approved')) {
        # do some stuff
    }

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.

The "feature flag tool" I use is a procedure called GetConfig() which is ~250 lines of code with comments and logic for overlays.

Please let me know if you have any questions about this method.

[GeorgeMac]

Nice. Something home grown effectively then? What kind of application are you building with?

[forgotmypw17]

I'm building a static site generator with optional dynamic components and lots of quirky features.

[mattbrewsbytes]

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.

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.

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.

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.

[GeorgeMac]

Nice. Have you had to develop any capabilites around knowing what changed, when and by whom? i.e. audit log or so on?

Just wondering what is your process in an incident when you want to know what changed in the system? e.g. so you can correlate observed error rate changes with a the enabling or disabling of a flag.

[Dirak]

> do you commit feature flags

It doesn’t really matter how you manage changes to feature flags, but using version control gives you a couple of nice benefits:

* gives developers the opportunity to describe their change

* let’s you roll back a problematic patch

* blame and bisect problematic patches

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.

> What feature flag tool do you use?

See https://engineering.fb.com/2017/08/31/web/rapid-release-at-m...

[GeorgeMac]

Awesome, that’s makes total sense. Am I right in thinking the practices described here at Facebook are more like progressive delivery? As in, instead of adding code to call out to some external feature flag or configuration system, new changes are deployed automatically in isolation and requests are routed to them progressively for larger and larger cohorts? All while validating the health of the change automatically?

[mapmap]

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.

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.

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.

[GeorgeMac]

Nice, makes sense. No external feature flag solutions here then? Just leveraging your languages build tooling and changing behaviour based on an environment key?

[mapmap]

Yes, exactly that. If there was ever any doubt about a feature and we wanted to roll it out slowly, we used the App Store tools.

[joshstrange]

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.

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.

[GeorgeMac]

Nice, cool to hear flags in conjunction with canary releases. Are your flags simply configuration stored in files that your applications read at runtime? Then you push those updates out with Salt?

[joshstrange]

Pretty much. Salt pushes out a supplemental config file that we use to build a php file (after merging with the defaults) with `define('FLAG_NAME_HERE', value);` that out core application reads at startup. We have different classes/roles for our boxes so we can roll out a flag to a specific type or some of a specific type if we are going to canary. I wouldn't say that our specific method is anything special but it works very well in practice.