Database Development Infrastructure

Introduction

I am often asked about database development best practices. The foundation of best practices is simple: Create a copy of the production environment to be used for quality testing.

Business Case

“It doubles the infrastructure costs!” Really? How much will it cost if you deploy an untested change and it takes you offline for a day? How much does it cost if you corrupt your user’s data? or your data warehouse’s data? A good QA / Test environment is a combination of risk mitigation and insurance against these business disasters. You have insurance, don’t you? Or do you not need insurance because you’ve “never used it”?

If you have a big ol’ honkin’ Production environment, it may not be worth duplicating the Production infrastructure. But you need to get as close as feasible to duplicating Production in some other environment. Will you need it for every change? Heck no. You will probably only need it for one change in one hundred. But that 1% will be worth all the time and effort “wasted” on the other 99%. I promise.

Conclusion

I believe there are two categories for database infrastructures: Those who have a test environment and those who will.

:{>

Andy Leonard

andyleonard.blog

Christian, husband, dad, grandpa, Data Philosopher, Data Engineer, Azure Data Factory, SSIS guy, and farmer. I was cloud before cloud was cool. :{>

4 thoughts on “Database Development Infrastructure

  1. I suppose I’m lucky, I’m moving to virtualize several of our web servers (that are extremely under utilized), and as a result, several servers are now without a purpose.  I moved quickly to bring all those servers to our development location so I could set up a development and testing environment!  It was the easiest sale to management I ever made.
    Funny how free is the acceptable price of testing, yet the substantial (and seemingly invisible) costs of not-testing is ok.

  2. This is fine, providing none of your production data is considered sensitive.  In our environment, due to auditory, regulatory, and government restrictions, developers CANNOT have access to real, live production data, containing credit card numbers, SSNs, and other sensitive data.  We do maintain seperate development, QA, and UAT environments, and all DB object changes are promoted upwards through those environments, but no data is exchanged between them.

  3. Hi Tracy,
      That’s a great point and I wasn’t explicit in my post about this: I said nothing about copying the data, merely duplicating the environment. There are several tools available to obfuscate the existing data or generate dummy data.
      Thanks for pointing that out – you’re absolutely correct.
    :{>

  4. "I believe there are two categories for database infrastructures: Those who have a test environment and those who will"
    I like that, gave me a smile on conld english Friday morning.  Sailors have a similar saying, there are those sailors who have run aground, and liars

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.