Updates to Sandbox

[ThomasRambach]

Having a sandbox tenant to do development work on new workspaces and updates to existing workspaces has been helpful. It's also been a hindrance. The only way to refresh the sandbox configuration to match production is to submit a support ticket to Autodesk and wait at least a couple of days for the ticket to be processed. This has slowed my development time greatly. Coming from a background in some web development where I pushed code updates to a testing server and then to the production server when ready in Visual Studio, and using a schema compare tool for database updates, waiting for anything is painful to me.

I'd like to see the following updates to how the sandbox's in FLC work:

• Add a comparison tool to show you the workspace and code changes that are different or missing between tenants.
• Ability to refresh the sandbox with a button push in your production tenant. Completion should be measured in minutes.
• Push workspace and code changes to production from sandbox.

These changes would accelerate development in FLC greatly. Vote up if you agree.

[giliar.defriesperez]

Do you often make changes to scripts in Sandbox and move them to Prod?

The differences between Sandbox and Production can be quite extensive, I'm trying to gauge what would be more valuable.

Giliar Perez
Product Owner - Fusion Lifecycle
Autodesk Canada Co.

[ThomasRambach]

@giliar.defriesperez If the changes are entwined with existing scripts or workspaces, then I use the Sandbox. If it's a new workspace and stand-alone, then I work directly in production.  

My biggest issue is when I'm working on an extensive change to an existing process in Sandbox, it's hard to capture everything you changed without writing it all down manually to copy it over to production. This includes workspace changes, script changes, data changes to picklist type workspaces, groups and roles changes, etc.

[Chris-M.Edwards]

We're a new user of FLC and have been using an SI (system integrator) to assist with our solution delivery.

For phase 1 we worked on the production tenant and deployed, for subsequent phases we will be developing on our sandbox tenant.

We cloned our production environment in the way you describe (support ticket) but due to the duration of our development cycle don't find this to be overly onerous, The Autodesk team react very efficiently and we can work with this current process.

However the comments you make about being able to ensure that we have captured all the changes made in the sandbox environment is something that we're encountering now; The SI has made changes in the sandbox tenant, has documented where the changes have been made and our team (part of the enterprise change management process) deploys the changes into the production tenant. Only it appears that the changes are not fully documented as it's a manual process and time pressures etc. have caused a miss.

My request is inline with yours but would be happy with just being able to extract the scripts & work-space definitions etc. (basically anything we configure in the application) into something (spreadsheet, document) that we could use to compare the 'configuration' with another tenant. We could manage our deployments based on this rather than having to check all scripts/workspace definitions manually (open, cut, paste into document etc.)

The push to production from the sandbox is something that would need consideration, particularly with the company controls that we have for production solutions and if built would need to take in security controls via roles (or something like that) into account.

[ThomasRambach]

@Chris-M.Edwards I feel your pain. Thanks for the idea support!

[Chris-M.Edwards]

@ThomasRambach It's a worthy idea, thanks for starting the ball rolling.