https://www.growthbook.io/ logo
Join Slack
Powered by
Hello - we would like to allow admins to use the G...
# ask-questions
p
Hello - we would like to allow admins to use the Growthbook chrome extension on a production website. According to the error message in the extension, you can only use it when dev mode is enabled. Is there a way around this? "Unable to locate GrowthBook SDK instance. Please ensure you are using either the Javascript or React SDK, and Dev Mode is enabled."
s
Hi Ian, there isn't a way other than enabling dev mode. The extension is primarily meant for debugging purposes in a development environment. May I ask for what purposes you wish to use it against a production website?
p
@swift-helmet-3648 we have a feature that can only be tested currently in production. We wanted to be able to turn it on just for people who are testing.
We can get around this probably but for our QA it would be a really great option to be able to test featues on prod before we roll them out
especially since there are so many tests running at once, being able to test different combinations easily on prod would be great.
I imagine its not recommended to turn dev mode on prod either.
would it be ok though if we turned dev mode on prod just for authenticated admins? is that something people do?
s
Yes, that would work. Conditionally set devMode based on certain criteria (e.g. a query param in the URL would also work)
p
@swift-helmet-3648 ok so thats what I did and it works great however it seems something else is going on. It doesn't seem to actually respect the overrides. I basically set a new "default value" using the chrome plugin however it dosnt respect this value when fetching it
It seems like when you change it - in the moment it works however as soon as you refresh it doesnt
s
Ok, that is intended. It's meant to be a quick way to debug - not a means of permanent configuration
p
interesting
Is there a reason it cant just persist? Seems like a big improvement to that tool. What our team currently has to do is modify each experiment in the admin and add their ids in order to force themselves into the xperiment
but that wastes a ton of time - a tool like this which is so close to being what we need, would more easily let our team test experiments. Even in staging and in dev having it persist at least for a period would be the preferred way this tool works
also the tool seems to remember the overriden default value
but it doesnt use it
s
It's an interesting suggestion and I'll pass it along to the team ... But it's purely for debugging purposes, that's why it's called 'DevTools'. For the problem of having to edit multiple experients to add user IDs, would saved groups help? https://docs.growthbook.io/features/targeting#saved-groups Basically, you can add a saved group to experiments, and if you need to add users, you can simply add to the group, and it will be referred to by all experiments that use the saved group
p
That is a nice feature for sure - but we have QA members testing different features all the itme - so generally speaking they want to be able to turn some configuration on temproarily for themselves alone, then turn it off
As a dev tool having it persist seems like the preferred way too
Example: Say I'm building a widget that only shows with one experiment. The existing tool requires me to enable it every time I refresh the page. But I want to be able to just set it and then it persists until I'm done working on the feature.
The other confusing thing like I mentioned is the overrides do seem to persist in the tool when I refresh the page -they just don't continue overriding
s
Ok. In that situation, our users typically create a new environment called 'development', and enable it only for that environment. They then have their dev environment leverage the SDK as they would in prod, with the only difference that they point to the development environment endpoint
p
Right but our dev team is 5 members - say you have 5 versions each dev is working on a different one
It also doesn't really solve the sort of stake holder problem - Where I want to share my features with stake holders and let them enable it so they can try it out on production before we turn it on.
Basically, I think the tool is great but that small tweak would make it so much more useful for both development and testing purposes
s
It would require significant changes. Right now we don't have any authentication for DevTools. We would need to implement that first to ensure you're authorized to persist those changes, right?
p
No the changes only persist locally for the person testing
persisted in coookies
So you'd just be writting the overrides to cookies, and then when you fresh it restores the overrides you had right?
s
I see, persisting between refreshes.
p
yep
If I have a feature that spans multipe page loads
this tool doesnt really help me debug it
because every page load it seems to reset everything
s
Yeah, let me relay to the team. Generally we would suggest creating a development environment to accomplish this, which I'm still not sure why that's less preferable
By doing the dev environment approach, you're implicitly doing an e2e test as well, which the DevTools approach may not uncover
p
we have a dev environemnt but where that fails is if you hsve multiple devs working at the same time.
Because then each dev would want a different version
But the single dev environment means they all have to have the same set of flags
s
You can define different payloads for different targets in an experiment
p
Not sure I understand. Using force rules? This is how we do it now where we have to find the users id, force a payload for that user id.
I dont want to take too much of your time on this - happy to explain our use case further if you or a team member would like to grab a time for a quick chat
s
Yeah, force rules was what I was referring to. Is it difficult for devs to go in and add their own force rule?
Sure, no problem. I can relay to the team and let them know you brought this up
👍 1
p
Not difficult but an extra step that takes more time. Find your id, add it as a force rule, publish, hope it worked. And we'd like to have stakeholders (non devs - qa, product manages, and others be able to try out features). I'd love it if there was a solution for non developer wanting to test out a feature in a simialr way. And like I said the tool is very close to being able to do that with the small tweak proposed.
s
Sure. For the non-developer use case, they would have to download the chrome extension and open up chrome devtools if I understand correctly
p
yes - thats fine
Most of our team is capable of using chrome extensions in that way - easy training of a tool
its better than having to go into the admin of growthbook (most of our team doesn't and shouldn't need access to that admin) and do all those other steps.
Because the tool is just changing local configuration of growthbook - they cant break anything where as giving them admin access to growthbook they could accidentally break something pretty easily
s
I understand. I would imagine the dev who is presenting to the stakeholder would take care of that, but ok
p
Yea, for some cases thats ok. But I guess just dont see a ton of value in this tool if it doesnt save. As a developer I'm not gonna use it if it doesn't persist accross the page refresh.
I dont currently use it for this reason, I just change the code to do what I want. But I would use it if it persisted for me until I was done with it.
Anyway, really appreciate your help and hearing out the use case. Let me know if you'd like to discuss further. Happy to help explain more.
s
Sure thing
76 Views
Open in Slack
PreviousNext
Powered by