8
To debug a Live issue from production it takes around 24 hours to replicate and copy database to development environment. user need to perform below steps
- Refresh from production
- Purge/Truncate tables script in sandbox using JIT
- Export database to Asset Library from Sandbox
- Convert database from bacpac to bak and import to tier 1 where debugging can start
Connecting to the sandbox database with a development environment takes some time also, but also is almost paralytic in it's performance. Unusable in a debugging fashion as the times it takes to re-create any bug will result in session timeouts making debugging impossible.
Solutions:
The holy grail here would be a sandbox available environment we could refresh and debug in. It doesn't have to allow deployments in the other direction, like a sandbox environment that would be used to validate/sign off a deployment package.
Second to this would be a direct to tier1 refresh from production or a sandbox. Something where Azure spins up the necessary resources to perform the conversions and truncations in the fastest possible way.
Third would be a way to insta-clone production in a "prod-debug" environment that'd be developer accessible but not used for any sandbox style deployments.
Fourth would be to discover why the processes above are taking so long (did something change? because these have dramatically dropped in performance over the last 12 months).
- Refresh from production
- Purge/Truncate tables script in sandbox using JIT
- Export database to Asset Library from Sandbox
- Convert database from bacpac to bak and import to tier 1 where debugging can start
Connecting to the sandbox database with a development environment takes some time also, but also is almost paralytic in it's performance. Unusable in a debugging fashion as the times it takes to re-create any bug will result in session timeouts making debugging impossible.
Solutions:
The holy grail here would be a sandbox available environment we could refresh and debug in. It doesn't have to allow deployments in the other direction, like a sandbox environment that would be used to validate/sign off a deployment package.
Second to this would be a direct to tier1 refresh from production or a sandbox. Something where Azure spins up the necessary resources to perform the conversions and truncations in the fastest possible way.
Third would be a way to insta-clone production in a "prod-debug" environment that'd be developer accessible but not used for any sandbox style deployments.
Fourth would be to discover why the processes above are taking so long (did something change? because these have dramatically dropped in performance over the last 12 months).
STATUS DETAILS
Needs Votes
Comments
A bacpac can be imported directly into a Tier 1 SQL instance, so the convert from bacpac -> bak is not necessarily required as such. The import of a bacpac does take considerably more time than importing a bak file.
This idea does highlight that the process to get the data from production to a Tier 1 is very tedious as highlighted. This idea of exporting production (or any MS hosted environment) to a Tier 1 would be extremely helpful and save a lot of time in getting data to a Development environment.
Category: Lifecycle Services