Hacker News new | ask | show | jobs
by miraantabrez 723 days ago
Agreed that you lose the benefit of "instant updates" if it's always controlled by a PR.

But Git-style version control with history, diffs, branches and pull requests are pretty useful for feature flags and other "app configuration".

Version history and diffs are great for knowing what flag logic changed when + debugging what broke prod.

Branches let you test and preview flag logic changes in your own isolated branch (which you can point the SDK at) — this is a cleaner approach to having a few separate "environments" like development, staging, production which can drift from each other.

Branches are also great for refactoring the schema / structure of all your flags, e.g. deleting a bunch of flags in one go.

Pull requests and approvals are great for when you're making changes to sensitive flags. E.g. you can lock down specific flags.

Pull requests are also great for onboarding nontechnical team members like PMs or sales reps so they can safely make flag changes themselves but require approval from an engineer (at least while they learn to use the system). Empowering nontechnical people is also why a UI is important.

Branching and pull requests are also a great way to prevent conflicts / overwriting other team members flag changes.

So Git-style features are pretty useful, but you also want the UI and you only want to enforce pull requests for specific flags or team members — this is what we built at Hypertune.

1 comments

You can get the same comfort of fast updates and history with a feature flag system developed using event sourcing, without having the overhead of git