Flags per developer environment?

[tmayr]

Hey there!, the product looks great and I cant wait to start using it!

While configuring our envs, one issue arose regarding environments

production/preview/development all seem to be shared environments, which makes impossible to test something 100% locally without messing with the shared environments (and changing another devs app behavior)

I looked around the docs and couldnt find any way to do either flag override locally, or just mock the flags that we need without needing to provide a configuration key (everything should be local at this point).

Before talking approaches (happy to contribute if needed), is this something missing? or am I looking at it the wrong way?

Thanks!

[dferber90]

Hey, thanks for reaching out!

production/preview/development share the definitions of flags (the available variants) but do not share whether a flag is on/off or the targeting rules. This is meant so that you have some guarantees over flags across environments, but can change which variant each flag evaluates to per environment (or even per user/visitor/trait per environment).

If you want to target specific people, you can use individual user targeting per environment.

If you want flags to resolve to different variants per development branch, you can pass the branch in as a trait and use a custom rule to resolve to a specific variant for each branch, but this should not be necessary in most cases.

Could you double check that you are passing a different envKey to configure() in each environment? You can find the appropriate keys to pass in under "[Your Project] > Settings > Keys > Flags"

I'm happy to jump on a call to make sure you're off in the right direction!

[tmayr]

I get what you mean about the definitions, and thats totally fine (and def expected, and nice to have) and I was using all the different envKey environments, for development, preview and production when I gave it a go.

Maybe I can explain better in an example?

We're developing a Cart functionality at the moment, which is being done in parts (cart view, product view modification, header with cart icons and actions), and we have some branches merged, some branches in development, etc, but until everything is done, this feature is disabled by default.

This means that a given dev, can be either developing against master on a feature totally unrelated to the cart, and they do not want/need to see it enabled. Another dev could be working on bits and pieces of the cart, so they need to see it enabled.

Seems to me that without user/trait targeting (as you mention) there's no way for a developer to have a specific set of flags enabled/disabled locally, without affecting anybody else (or even getting into the UI for that matter, because there could be security/credentials reasons on why they cant).

I'm thinking of a JSON you can specify somehow that would override default and platform flags.

I hope that makes a bit more sense!

[dferber90]

Ah, I got you now. That's an interesting use case! I'll give this some more thought.

user/trait targeting were indeed the solutions I had in mind to solve this, but I can see how this could get annoying if you're switching branches often.

Aside from the one you proposed, here are some early ideas that come to mind:

• Make it possible to have a hard overwrite for flag resolutions in the client (your suggestion)
• Making it possible to set default traits in configure(). Then your branch name could be passed in by you as a default trait. It would be passed to every flag evaluation. You could then adapt the feature flag rules based on the passed in branch. The default trait could be set to an environment variable containing the current branch name. You could use http://npm.im/current-git-branch inside of next.config.js to gather the current branch name. This solution would require a restart of the Next.js application after every branch change, to propagate the new env variable value.
• Making happykit aware of the current branch, and supporting branches natively in the UI. This would be super intuitive, but limits this solution to branches. Could there be something similar we'd want to target on aside from git branches? Nothing comes to my mind yet.
• ~Abandon the production/staging/development thing and build it on top of branches. This would be the most flexible but kinda suck as you'd have to maintain your feature flags across many different, sometimes short lived, branches~

What do you think? Any preference?