THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

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.

:{>

Published Thursday, November 18, 2010 12:00 PM by andyleonard
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Shannon Lowder said:

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.

November 18, 2010 1:10 PM
 

Tracy McKibben said:

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.

November 18, 2010 1:51 PM
 

andyleonard said:

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.

:{>

November 18, 2010 2:09 PM
 

Greg Lucas said:

"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

November 19, 2010 3:21 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement