October 10, 2011 at 1:26 pm
Hello...
I'm responsible for maintaining my company's database environments for development and testing, and I have been wondering about what other big companies do or what their approach is to keep their environments data up to date or "fresh" for developers/testers to work with. Our current procedure is very time consuming and impacts both our production servers and the lan while generating full backups and transfering them through lan to the dev/test server, thus I want to make a change, whether it be making the whole task faster, or reducing the impact on the production servers. I would like to hear (read) what you know or what your thoughts are regarding keeping dev/test environments updated.
I have cosidered performing differential backups, but there's the problem that full backups are being generated by the tool used for storing daily backups to tape, which keeps "reseting" the differential base.
Another thing I have thought of... are there scenarios where the real data from production servers is put available for developers/testers to work with? or do they use a *special* database filled with ficticious data? (something like an "AdventureWorks" database) or would this result in a negative impact in the work of developers/testers while not having the real data?.
I really hope you guys can give some clue on these matters, all your comments are greatly appreciated (and i apologize if my english is not very clear). Thanks in advance.
October 10, 2011 at 1:38 pm
Your english is fine Keopx and there's a few schools of thought on this.
First, though, is the rules of your industry. IE: Healthcare and HIPAA. You must destroy some data once it leaves the audited environments. These types of things will affect your options.
One school of thought says after a deployment bring production back down to dev/qa. This is more common in sprint-locked environments where they don't do work across sprints. It forces the developers to be coding against exactly what they're going to be running against during the prod launch, with the code being a bit out of date.
Another option is the DEV is sandbox only, QA is recursion monitored data so that all previously occuring known 'bad data' issues can be tested against any new work, and UAT (User Acceptance Testing) and Prod are the only 'good' version of the data. This is relatively common as well.
Using this method, if you have to do a production debug, this is the only time you'd bring a copy of the database(s) down to a developer's access. Usually on a QA server somewhere with limited access.
Under no circumstances would I be restoring a production DB to dev daily. I do work there and I don't want to have to constantly rerun every script I haven't deployed to Prod yet. QA can get jammed up for weeks on occassion as Users nitpick the acceptance testing... or are too busy doing Year End reports to care about some new feature in the testing track.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 10, 2011 at 1:54 pm
Keopx (10/10/2011)
Another thing I have thought of... are there scenarios where the real data from production servers is put available for developers/testers to work with? or do they use a *special* database filled with ficticious data? (something like an "AdventureWorks" database) or would this result in a negative impact in the work of developers/testers while not having the real data?.
Our dev database is refreshed from prod only on request. So new development can sit on there for quite a while without fear of being written over. The test database is automatically refreshed nightly by a job. Once development is done, the code is applied to test and the testers can verify the changes on very recent data. The testers are the same users that work on prod, so there is no reason they shouldn't be verifying on data and code they see everyday.
______________________________________________________________________________
How I want a drink, alcoholic of course, after the heavy lectures involving quantum mechanics.
October 11, 2011 at 5:50 am
If the database schema is same in PROD and QA / DEV environment, you may pull some data back from PROD (subject to legal issues) to DEV environment.
If this is scratch development of a solution then your DEV environment will have the higher version of schema than PROD. In such case you have no other option except creating dummy data for DEV and QA teams.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply