September 5, 2012 at 7:19 pm
Is there a best practice for what source data to use during development.
I could use data from the source development environment, but this poses the problem that it may have architectural differences to production, or have data anomalies not in production (or lack data anomalies in production) and not show the same changes to data that occurs in the production environment.
I could use the production environment, but it introduces risk.
I could take a backup of source data, and work from the back up, but this isn't always practical with large databases and wouldn't allow me to see changes.
Currently I have a tendency to use a backup to understand a new data source initially and then work with production data so there are no surprises.
I'm wondering how others approach though
September 6, 2012 at 12:25 pm
For me, testing in production is only considered an option in extreme cases and never would be part of a normal development lifecycle plan. I like to restore production backups into my dev environments periodically. In some cases I have had to develop a data-scrub process to run post-restore to maintain PCI compliance. For VLDBs sometimes a periodic restore was not practical. In those cases I would cherry-pick specific tables to refresh from prod (scheduled SSIS or bcp job to output a table to a file that I could use the next day for testing) during a maintenance window to get fresh data to test with.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
September 7, 2012 at 7:27 am
We keep both development and testing environments and restore copies of live back to both as above.
Regularly restoring a copy of live to dev or test is also a good check that your backups are successful.
September 7, 2012 at 8:58 am
I've tended to use copies of production, but sometimes obfuscated for security purposes.
My company (Red Gate Software) makes a data generator that can build data for you, in all shapes and sizes.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply