https://www.growthbook.io/ logo
Join Slack
Powered by
Hello we are moving to a hosted feature flag syste...
# ask-questions
q
Hello we are moving to a hosted feature flag system and on launchdarkly it seems like pushing feature flags to the flag management platform is an enterprise feature so I started looking for alternatives. I was going through the growthbook docs but it's unclear how this is here. Basically: I want the developers to be able to define the feature flags in code and push it via CI/CD. Ideally (optionally) define basic on segments like “beta users” without causing the config push to undo changes like enabled for specific users done on the management platform.
I guess my first question is just I can see there's a settings json in docs, but it's unclear if this is just local or I can push that to the hosted solution via CI. Is there docs for this anywhere that I missed?
f
Hi Kit - yes, this is how and why we built GrowthBook. Features are defined in code, and then how they are deployed/rolled out is determined from the GrowthBook UI
Happy to give you a quick demo if you like
the features JSON can come from anywhere
q
Thanks, I don't need a demo yet, I'm just wondering how does the features defined locally in my code become feature definitions on the hosted version as far as I can tell every document talks about pulling flags from remote to local https://docs.growthbook.io/app/features implying there's a setup step needed for every flag on the platform.
Same here
I understand that the developer can make a local feature definition that's overridden from remote, but I don't understand how the remote definition happens so the non developer can interact with it.
f
the typical case is a developer wraps their feature in a flag
and then the rules for showing it are determined from the UI (in a non technical way), as a rollout, experiment, etc. This step generates a json file with the rules, which is pulled to the local SDK for use when showing to a user
q
Right but the feature flag itself is created in the UI by a user right? They don't get pushed?
f
in the code, you'd define the feature name, which need not exist yet in the UI (and will be off by default). This name needs to match a feature and rule definition in the features JSON (which is typically done from the UI).
there is no communication step in our SDK which would automatically create the feature in the UI based on the existence of that name (currently)
but that JSON file could come from anywhere, and the schema is pretty simple
q
Cool, yeah that's what it seemed like. I want to avoid this coordination step ideally.
f
I see, how would the flow work ideally for you? perhaps we can add something
q
Oh I'm too small to be worth chasing after currently, but at a bare minimum I would want the developers to define the features in a config file which gets pushed on CI/CD and have the feature flags get auto created.
The ideal situation would be if we could push a feature flag that is set to be always on/off, and have segments which have on/off defined. But I understand it can be a bit messy doing that in the relict when you also control settings via a UI.
f
we have some features similar to that in beta now, let me talk to the team and see what we can come up with
The hacky way would be to do something similar to this:
q
Cause we have basically general availability features, and opted in beta customers in a segment. Then on the UI I would expect it to be more up to sales/customer success on a case by case
f
but append to the json manually if not already set - that can be done in pure code
btw, when you evaluate a feature, there is a default value you can set. But, ya, the creation of the flag has to be done manually atm.
28 Views
Open in Slack
PreviousNext
Powered by