Introduction
I am frequently getting requests for a new server to do this or that. Running through the usual questions to determine scope and scale, the price can get high pretty quickly. Inevitably, talk turns to ideas on how to cut the cost while still delivering a robust platform. Typically this is when the questions about skipping the Test, QA or Stage environments come out. The logic is usually that a production server is a must have, a Development server is good to have and anything else is gravy.
Applications running third party (off the shelf) tools can get by just fine without even a Development environment while heavily customized applications need many more environments.
My goal here is to lay out the different environments as well as what I see as a the use for each.
Local
The Local environment refers to an individual developer’s desktop. On this desktop there may be a database server, web server and application server. This is the primary Development environment where things are often built and tried out without fear of angering the rest of the project team.
Chances are that if your organization has a developer you have a Local environment.
Development
The Development environment is the place where everyone’s work starts to come together. It is the first environment that would contain any true servers. Depending on application architecture, this environment may be entirely composed of servers or in the case of client applications still include developer desktops.
Servers in the Development environment are typically given the drive layout as production to allow for restores and Testing of scripts but may only have a fraction of the number of processors, memory and spindles that a production server would have.
I like to compare the Development environment to a busy lake on a hot summer day. There are a lot of people doing their own thing, headed in their respective directions at high speed. The size of your boat (project) usually determines who has the right of way and everyone must adhere to the local customs while keeping their eyes open to prevent collisions.
Testing
The Testing environment is much more of a nice to have environment. For all intents and purposes it is a second Development environment with one important difference, change control. The Testing environment is where code is tested before turning it over to the QA department. It is also the environment where builds are rehearsed to minimize downtime during releases to the QA environment. Developers typically do not have access to change any objects in the Testing environment.
It is very important that the drive layouts between all environments match for manageability purposes. It is even more so for the Testing environment due to how often restores are done to quickly get back to a clean state before Testing the next build.
QA
The QA environment is one of the more important environments. This is the environment where the QA team does their magic. The usage pattern here tends to be low volume and slow paced, so hardware for the QA environment can be the same as that used in the Development environment.
The big thing to remember about the QA environment is that it must be as stable as possible. This is not the best environment to rehearse releases because any problems are likely to put the QA team behind schedule but, absent a test environment, it is the only place many organizations have.
Staging
The Staging environment is tied with production for being the most expensive environment. The Staging environment must be run on exactly the same equipment as production. The typical usage of Staging is automated load testing, user acceptance Testing and even training on important new features.
Without a Staging environment careful scheduling would have to be done to prevent collisions in the QA environment. Otherwise QA testers may be entering defects for behaviors caused by user acceptance or load testing activities. User acceptance testers may also report back to their peers that the changes to the application make it slower when in fact it is just the environment they are testing in.
Many organizations house their Staging and Production servers in separate locations for disaster recovery purposes. Attempting to do the same with only a QA environment would make the release process much more complicated in a disaster recovery scenario as changes would have to go directly from Development or Testing to Production.
Production
This is where the magic happens. I think everyone understands the need for a Production server so I am not going to spend a lot of time here. The point I would like to make is that the more money you spend on your production environment, the more environments you should have to back it up. There is no point to spending a small fortune on the best HA cluster you can find without having the capability to do real release management and disaster recovery or worst case: release management in disaster recovery.
Conclusion
I hope I have provided enough information to begin to ask the right questions when working with users to price out servers. Being able to properly educate users either helps them come to a realistic evaluation of their needs or a business case for 6 or 7 brand new servers that you can brag to your DBA friends about.