cancel
Showing results for 
Search instead for 
Did you mean: 

Refreshing lower environments

robin_wylie
Level 3
We have gotten the point where it would be good for us to refresh our lower developer environments from production to clear out cruft. Is there a set of best practices or instructions on how to effectively refresh a lower environment from production? 
4 REPLIES 4

AmiBarrett
Level 12
In theory, you could do a sql export/import between your two databases.

John__Carter
Staff
Staff
Depends on whether 'refresh our lower developer environments from production' means 'clone the prod DB and use it as dev' or 'export all processes from prod and re-import into dev'. You could even consider creating a brand new dev DB and import everything from prod - an extreme option, but it would give you a clean slate.

robin_wylie
Level 3
In this case, I would think it would be more like 'clone' production and use it as dev, to get your development environment back to a state closer to what production is.

John__Carter
Staff
Staff
Robin - the advantage of a prod clone is that everything is there. The downside is the DB will be big, with lots of data (log and queue history etc) that you're unlikely to want. And maybe more importantly, prod might contain sensitive information that the developers should not have access to (credentials, customer data etc). So before making a clone available, you might want to clean it up first.