Good morning, Context: I'm doing some exploration on evaluating Descope as an A&A solution, and i'm looking for some feedback on the problem described below. Does Descope have any recommendation for "Best Practices" regarding a dev-cycle (or dev pipeline)? Longer read about what i'm trying to solve >>> I'm trying to imagine how would the pipeline of the development process to production look like, and i am having a bit of a hard time. It seems that when I define a project in Descope and make changes, they're immediately reflected "in production". that creates some challenges: 1. the ability to explore and make changes to existing setup without actually impacting the production environment (some kind of a development environment or "staging" environment like your competitors have 😉 check out FrontEgg or WorkOS) 2. the ability to run end to end tests and integration tests for Login etc... that are not running against our Prod, and guaranteed not to impact it. 3. Not having a multi-phase rollout, is more error prone in breaking production, and not being able to revert (given there's no way to export / save / version the configuration in a Descope project) The only way i could figure out how to do this, is by creating a parallel project ("company-dev") that would have a tailored setup for exploration and so on, and another project say, called "company-staging" that would be used for e2e and manual testing with features, etc... before releasing to production. The thing is, this is very hard to do today from the UI (Descope Console) from what I can tell, and very error prone doing everything manually. My workaround: I thought that I could create a dedicated app (not necessarily with a web interface), that would perform "cloning" of projects and would be managing the configuration locally on my system (in some file format or whatever), and by that would allow me to be making changes and managing all this pipeline and have versioning. My question (again): Does Descope have any recommendation for "Best Practices" on how to do a dev-cycle 🙂 ?

Hi, This is a great point we are aware of, also as developers and that fact that we use Descope for our own Authentication. At the moment, the best practice is to have another project for production (as you mentioned), and use the flow/styles export/import feature to move the data between projects. Your other suggestion can also work. @gifted-florist-65280 our head of product can elaborate about future plans around this area.

thanks @ancient-motorcycle-2291 for your answer. 1. could you please direct me to the export/import feature in the docs? I wasn't able to find it there or in the UI 2. would love to hear about your future plans

small note to add, we will support soon also to import/export from SDKs

cool. can you give a time frame for "soon" ? could be helpful

This or early next week, you can follow #C04USJVE5GW

hi @important-river-90900 🙂 as mentioned above - the new import/export of flows is just the tip of the iceberg of the larger process we’re planning. in the future - we want to support a simple yet intuitive SLDC process, which will be done using multiple features, including: • relations between projects, that will allow you to easily transfer flows and authentication configurations between them • more supporting tools for debugging a flow - both for manual and automatic (part of your CI/CD) testing ◦ the first one we released is the ‘*flow debugger*’, but there are a lot more ideas for different phases of the development process • project actions, such as creating and cloning (as you suggested above) it would be great if, once we start working on these features - we could consult with you on how you would expect each of these to work 🙏🏼

thanks @gifted-florist-65280. sure. would be happy to