GM. 1. is there a way to duplicate a project in de...
# ask-a-descoper
i
GM. 1. is there a way to duplicate a project in descope (for experimentation purposes without effecting the project in Prod)? 2. is there a way to "export" the project to a file so it can be saved and import/upload it later? I'd like to keep it as part of the state in the Git repo so I can revert changes easily, and go back in time.
a
Hi, Today we allow to export/import flows and styles (from both UI and SDK). We do have dev/prod and environments as part of our roadmap, which you will be able to see diff and promote changes to production. @gifted-florist-65280 can add more information about our vision.
i
thanks @ancient-motorcycle-2291for clarifying. is there an expected timeline on the dev/prod environments feature? @gifted-florist-65280 i think having the ability to clone a project with its defined tenants, roles, SSO and every other configuration would be of great benefit to the dev-cycle, and the ability for the r&d to experiment with new Descope capabilities fast without impacting the rest of the team.
g
hi @important-river-90900 at the moment there’s no concrete timeline to the environments epic, but we do want to release some supporting features that will build into it. i understand the need for role and permission migration, and also flows and styles (which we currently support manually) - but it would be interesting to understand the use case for migrating tenants (which are, at least in my mind, similar to users from a usage perspective). could you maybe elaborate?
i
sure. i will try to make my case down below, of course while writing these lines, i realize that this is a CR/feature that will require some attention in design on your side. However. the point was not about migrating the tenants. it's about the ability to move faster and experiment with changes for the project (incl. all configured tenants), in a contained setup. imagine you had in your project one setup for
prod
and one for
dev
. and developerA wants to work on implementing some changes in
flows
while developerB wants to make changes to the "Welcome Screen" and developerC wants to configure SSO for a new Tenant that made a purchase. You could either: • make the work serial. where developerA has to finish making changes before developerB starts. - slow. • allow everyone to work on the
dev
env, but then r&d needs to be in a very close sync in order to make sure developers are not stepping on each-other's changes and not having changes impacting one another, not to mention undesired changes left on the
dev
env that should not be promoted to
prod
just because developerD wanted to check something. I think that when you have only one
dev
environment, it becomes a bottleneck. I hope that makes sense.
👍 1
g
thanks for explaining! would you be open to a short zoom session to think these ideas through? it would be really helpful for us 🙏🏼