Printed 2017/07/23 03:31PM

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 is much easier than (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.

Copyright © 2002-2017 Redgate. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.