[m11a]

Nice thing about git feature flags: the state of your system is all in one place. It changes only when you do a code release, which includes feature flag values, or an infrastructure release. You can easily see, just off git history, when the state of the system changed (and what changed), which makes incident debugging much easier.

With DB feature flags, there's one more source of truth for changes to production infra.

(downside, of course, is that changing feature flag values is much slower using git vs DB)

[bullcitydev]

This! 100% All the same benefits of config as code, infra as code. And with feature flags if something goes wrong its a simple `git revert` to get back into the previous state.

Another benefit is you can easily replicate the current (or previous) state of production/staging/etc flags locally just by doing a `git clone` and then run our self-hosted version locally. Its a single binary, can be installed with curl or homebrew and can read the flag state from your local filesytem.

This allows you to test your code locally or in CI with the same state in production

[radicality]

Maybe I’m not fully understanding what this product is doing. For something like configs/feature flags, it imo should be dynamic.

I was thinking that git (in a separate repo from main code) would be used to store the changes to configs, but then you would still need a system that tails the git changes and distributes them to clients.

That’s the way config serving was done at Facebook - a mercurial repo with all configs and tooling to edit configs which creates mercurial commits. Then, the mercurial repo is continuously tailed and values are saved to ZooKeeper, and then client libraries read config data from zookeeper / subscribe to updates / etc.

[GeorgeMac]

This is actually how it works.

Flipt is live tailing the repository and serving this dynamically to the clients.

The repo with flag configuration can be solely for flags, or alongside other infra configuration on in more of a monorepo. You decide how you want it setup.

Obviously if it is alongside code, you may to contend with CI in order to validate a change. But with the rules in CI or other monorepo tooling, what runs and when can adjust this behavior to improve time for configuration to become live.

Once a configuration change is integrated into a target branch in the repo, then it becomes readable for Flipt and servable once fetched.