Readit Newscool. Looking forward for this.
Also S3 (+ azure and GCP) would be a good 'edge' k/v store.
Someone could start with Github in a simple project, migrate to S3 to handle more requests and then migrate later to a full server solution... All of this keeping the same client codebase
Love this, and definitely where we're going.
We already support S3, Azure and GCS, as well as OCI (any compatible registry) as a source in the open-source server-side evaluator. So if you pop a deploy step to any of these sources from your Git repo, you can use them via the Flipt server process as a source of truth in production. Our server-side and client-side SDKs can source from Flipt in these scenarios.
But, we are keen to both explore skipping the Flipt server middle-man for client-SDKs, as well as make the publish step to these locations a simple configuration process in our UI. To avoid having to write things like GH actions to achieve the end to end result.
Thank you. I guess I was imagining that the flags lived in your source code repo, and required a commit and push to update, thus triggering some CD build and redeploying your app anyways.
You're not wrong there at all. That is a very reasonable assumption and I think the default behaviour with most early CD pipelines. Every commit leads to a deploy event.
However, this can be changed, so that not all commits/pushes are treated equally during CD. Either by using rules to ignore changes to certain sub-directories / files or through having reproducible builds and skipping the process restarting parts when the resulting artefacts between two commits haven't changed (e.g. the digest of a docker image not changing from one commit to the next).
This is often an optimisation though, and takes time/effort to put in place.
I worked with a mesos config app, backed by git. Watching the whole go down when github died resolved none of us to ever trust it again for that sort of role.
Use s3. Honestly.
On this, we support publishing the state to object storage (S3, Azure, GCS) and to OCI as well in Flipt.
Flipt Open-Source can be run to consume from these locations. You can go as far as configuring a workflow to publish on push, so that you can combine our managed UI with any of these distributions methods through Git.
With any of these backends (including Git), we periodically fetch and cache data in-memory. Evaluations work on an in-mem snapshot. So temporary downtime doesn't propagate into your applications being unable to get flag evaluations.
You can get around most of the consistency problem by "scheduling" the change. So, if I know it is going to take 2 minutes to make the flag available to my entire infra, I can schedule it for 5 minutes from now (could even make this configurable—a "default feature delay") which moves the consistency problem to infrastructure clock-sync.
Thats a great idea! I hadn't thought of combining it with a schedule for when a change is readable.
If a user can turn a toggle on and off using a UI, what is even the point of Git?
Full version control, which can be collocated with other configuration for the rest of your system (thinks terraform or k8s manifests) means it becomes easier to build a picture of how your system was configured at a given point in time. Because you have a single history to walk.
I like this design choice!! Wondering, what will be the biggest drawback pop in your head compared to traditional DB config or feature flags solution?
Complexity of initial implementation was certainly one, as we developed it. It’s not the most well trodden path for this kind of problem (well trodden for other kinds of apps). Obviously it lacks things like relations and schema, that we have to build on top of data in flat files.
One thing is that running Flipt open source on your infra, means running replicas all sourcing from the same Git repo. They currently polls for updates and this means eventual consistency comes into play when you scale. We have plans to help mitigate that with cloud though (pushing updates from cloud to your self hosted runners).
This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere.
"Feature Flags that live inside your code" - That's just variables, no?
Feature flag state is still served dynamically through Flipt. Your code doesn’t have to redeploy for the changes to “become live”. That’s the main benefit.
Means you can experiment and target different cohorts with variants of your app without restarting processes everywhere.
Can this probably be done with GitHub Actions and GitHub Pages without any 3rd party platform (just no UI)?
Flipt itself is open source and includes the git backend. So if that works for you, great!
In our experience a lot folks came and said… but the ui is so important for us to be able to use a feature flag tool.
For example, this sure does look like Dagger <https://github.com/dagger/dagger#what-is-dagger> in its use of golang-as-ci <https://docs.dagger.io/quickstart/daggerize#construct-a-pipe...> and plausibly "run ci locally"
Dagger doesn't ship with a dashboard (that I know of) but I also struggle to think of why one would want an artisanal dashboard when <https://docs.github.com/en/actions/use-cases-and-examples/de...> and <https://docs.gitlab.com/ee/ci/environments/index.html> exist in close proximity to the existing CI infrastructure. I guess if one is trying to be "CI agnostic" but my life experience is that trying to be CI agnostic leads to a lot of NIH which one cannot hire for and cannot take to the next job
While this is in the CI adjacent (and indeed I am a big dagger fan and certainly inspired by it), this predominantly lives in the CD realm instead.
In particular, it has helped us with something that I feel is missing in the GitOps space, which is the connective tissue between environments. Automating updates to app versions directly in repo and then bringing that altogether into a single dashboard where I can see what does my repo say the desired state of the world should be. Ultimately, we want to surface what the actual state is too.
We’ve hedged our bets a bit so far and left room for non GitOps CD to potentially slot in too. But not sure if we should just double down and be explicit and go hard on GitOps.
When you say a “why not…” you’re referring to like a Glu compared with X section right? That’s a good idea. I will add that!