rubenf
rubenf2y ago

Collecting feedback for a new feature

Collecting feedback for a new feature called "Environment" which would have 2 values: Staging and Prod. Essentially, Variables and Resources could be set to have different values based on the environment chosen (which would be set at the run level or workspace level) and users could be barred from having access to prod values. I'm thorn on the subject because there are some overlap with the concept of folders in which you could have "staging" and "production" folders.
7 Replies
rubenf
rubenf2y ago
by default, all values of resource and variables would be considered to be both for staging and prod, but then you can override the value for each env specifically if wanted
Sindre
Sindre2y ago
Tried to give this a bit of thought. And my 5 cents would be to understand how your users are developing the scripts. So for me, staging makes sense when developing and I do not want to touch the prod env. And before I "launch" the script to production, this would be enough. But when I have a script or flow in production, and I want to iterate on it. I will be changing a live script. I could fork the live script and copy paste it back in, but from my point of view I would like a "staging" area for scripts/flow also. Then I would see the benefits. If it's only for variable and resources it feels like I'm missing something. In general I feel that Zapier is not something to look up to, but they are dealing with changes in their zaps ok now. E.g they have a way of editing and saving it as a draft before publishing to production (https://help.zapier.com/hc/en-us/articles/8496260938125)
Zapier
Create drafts of your Zaps
Drafts allow you to make changes to a Zap without turning it off. Once you’re happy with the changes, you can publish the draft and it will replace the existing Zap. When you create a draft of a Z...
rubenf
rubenf2y ago
I think for draft right now I would prefer to keep the use of folders because it's much easier to reason about with filesystems and local sync. I think your point makes sense but the main use would be for bigger org where you want to keep the same flow but have it hit different apis. Essentially some developers would only ever use the script on staging while the more privileged user would use it against prod. One idea is to only have it for variable and not resources for now to simplify it even further
Sindre
Sindre2y ago
Hmm. Could you elaborate on how you think on using two folders as staging and production? I'm not sure I understand what you think are best practice here
rubenf
rubenf2y ago
Yes I was thinking of graduating a script by moving it to production folder. But I think we lack a clear way of just copying instead of renaming/moving. But I will do that
Unknown User
Unknown User2y ago
Message Not Public
Sign In & Join Server To View
rubenf
rubenf2y ago
yes, you can do that at the workspace level or folder level and you can theoritically do that once we have env since only the github token could have access to the prod env