My name is Peter Skoglund. I have twenty+ years experience in IT and I have work with SQL Server since version SQL Server 7.0. I work as a development DBA and spend all my days with development and database administration. My quote is "The first step to improvement is to have the gut to question".
Planning the Development, Testing, Staging, and Production Environments for SQL Server part 1 (Republished)
When asked about how to plan the ideal dev, test, staging and production SQL Server environments it’s easy to get carried away about the problems/possibilities about:
· How to get nightly restores from Production.
· How to solve the storage issues.
· How fast does the environment need to be, large/cheap SATA drives instead of small/expensive SAS drives.
· How to get the server configured identical to Production.
· How to handle sensitive data.
· How to handle automate daily builds from developers.
All of the above is important but I find that people often forget one thing that will greatly facilitate access, connections strings, future migration and save allot of questions and that is the DNS alias. Remembering http://www.google.com/ is much easier than 10.72.49.222 (With the impending implementation of IP Version 6, IP addresses will be even harder to remember). And when QA or developers people ask you what’s the name of the Test SQL Server you know you are in trouble.
But by implementing a unified DNS alias standard for all of your SQL Server environments you avoid the problem. Example
Environment DNS alias
Everybody’s life got easier and you’ve got a free weekend.