How frequently would you refresh your development database from production database?Since you will find various kinds of projects (focusing on different domain names) I must understand how it has been done and also at what times(days/several weeks/years) it's being carried out ?


While working at Callaway Golf we'd an automatic build that will completely refresh the database from the baseline. This baseline could be up-to-date (from production) just about every day. We'd a collection up scripts (DTS) that will do that for all of us. Therefore if there is newer and more effective and fascinating information we're able to easily get it done a few occasions of day, once per week, etc. The important thing here's automation to do the job. If you can easily do then when it's done is actually only determined by how carrying out the job impacts the burden around the production database, the network, and how long it requires to accomplish it. This might obviously be setup like a schedule task to operate at off peak hrs and prior to the dev team will get in each morning.

The important thing things in refreshing your development database are:

(1) Automate the refresh via a script.

(2) Obfuscate the information inside your development database because you don't want your designers to determine the actual data or you might perform some sampling of the production database.

(3) Decide the regularity from the refresh -- It's my job to get it done once per week.

Is dependent on which type of work you are doing. If you are debugging problems that are carefully associated with the information, then frequent updates are great.

If you are doing data Quality Assurance (which frequently involves writing code to identify and do the repair, you need to develop and test from the production server), you will want very fresh data. Unhealthy data that's probably the most valuable to repair may be the data which was just placed or up-to-date today.

If you're writing client code, then infrequent updates are great. Frequently when I am writing C# UI code, I possibly could care less exactly what the information is, I simply care whether it turns up within the right box on screen.

For those who have data with any security issues, you need to stop using production data--i.e. never update from production--and obtain a good sample data generator. Writing a great sample data generator is difficult, so third party items are what you want. MS Data Dude involves mind, and that i recommend Sql RedGate's data generator.

And lastly, how hard could it be to obtain a copy from the production data? If it's cheap and automatable, just customize the copy every evening. If it's costly (necessitates the attention of the very busy DBA), well, resource constraints might answer the question for you personally regardless to those other concerns.

We often refresh every few days, or possibly once per week approximately if situations are "normal," though if we are looking into something amiss we might achieve this more a lot more frequently.

Our production database is all about 1GB, therefore it is not really a trivial factor copying around. Also, for all of us there's generally no burning want to get current data from production in to the dev systems.

The "how" is only a MySQL "backup" and "restore"

In many cases, refreshing the dev database really is not that important. Frequently production systems have much more data that needed for development, and dealing with your a sizable dataset could be a hassle for many reasons. Good examples include development around the interface, where it's more essential to possess some data rather than anything specific. Within this situation, it's more customary to thin the production database to some more compact subset of real data. Once you do that once, it isn't really that vital that you update, as lengthy as all schema changes are pressed with the dev database(s).

However, performance bugs may frequently require production-sized databases to have the ability to reproduce and identify bottlenecks, so within this scenario it's very helpful with an almost-realtime database. Many issues may promote themselves using the exact data utilized in production.

We often always return to an on-demand schedule. We've a variety of databases which are utilized in a suite of programs. We avoid automatic DEV databases b/c a number of our code changes involve database changes and I'm not going anything overwritten.

Not whatsoever, the dev databases (one per developer) get setup with a script or similar a few occasions each day, possibly around 200 occasions when running db tests in your area. Including a few records for experimenting

Obviously we still require a database with a minimum of areas of production inside it, for integration and scalability tests. We're striving for any daily automated refresh. But we are really not there yet.