Refreshing lower environments
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
13-10-18 01:22 AM
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
13-10-18 02:34 AM
In theory, you could do a sql export/import between your two databases.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
15-10-18 04:13 PM
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
15-10-18 09:29 PM
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
16-10-18 12:32 AM
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.
