Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
Development --> Staging --> Production

A pretty typical workflow. This is fine.

"Fine, you want a 'Beta' Environment to show off stuff to some users/customers that isn't quite ready for Prime-Time."

Development --> Staging --> Beta
                        \-> Prod

"What do you mean 'Pre-Production'? That's what Staging is for."

I've seen a few (FEW!) cases where more might be called for, such as heavily-audited industries where elaborate testing must occur, but even they seem to get out-of-hand. (I once worked at a place with 11 separate environments!)

Is anyone else seeing this Environment-Sprawl? How can we managing the Developers (and Management) who thinks that these are "important"?

Even my pleas of increasing cost and complexity seem to be getting ignored, and it feels like some of the reasons are laziness. Beyond 4-5 environments, my spidey-sense begins to tingle...

share|improve this question
Apologies! Hit <ENTER> in the wrong place and the question was submitted prematurely! – gWaldo Aug 14 '12 at 15:00
"Is anyone else seeing this Environment-Sprawl?" Hell, yes. But depending upon the business it may be necessary. We have branch & trunk enviros for Dev, Sales & QA and Staging and Production (branch of course) enviros. Our architecture also has a backend & frontend and the backend has additional enviros (Preview and What's running on Prod). It's madness! – HTTP500 Aug 14 '12 at 17:01
up vote 1 down vote accepted

There are lots of valid reasons for going outside of this typical workflow. We don't have a QA environment like @CamelBlues suggests, after all code should be QA's before it is marked as complete and ready to move to staging. We utilize QA at development time and therefore don't need a QA environment.

Either way, major changes to the code, like UI replacements or things that cause the need of an additional branch of development often also require a different place to test and stage than the main development environment.

For instance, if I'm replacing my UI and porting my application to a new MVC system I might create a new branch to accomplish this in the source control repository. However, I can't run my legacy code and the new MVC code together so we would need a new environment to host that branch until it completes. Especially if you still have to fix bugs along the way.

Just remember... this is EXACTLY what virtual machines are for. You might even be able to get away with the 60-90 trial licenses from Microsoft (if thats your platform) for development and testing purposes. It really shouldn't matter how many environments are requested (within reason and compared to your team size) because you should have a platform to easily and quickly spin machines up, thats how most larger dev shops operate and actually allow devs and testers to check-out VMs to use.

Update: Just checked our environment and we have a pre-production as well. Its used by the release & deployment team to test the instructions and fixes to have a dry run walk through prior to actually touching the production boxes. Gives them a buffer.

share|improve this answer
I respectfully disagree that this is what VMs are made for. However it is a good use-case once the infrastructure is set up to dynamically allocate new environments with complete provisioned stacks, AND a culture that remembers to clean up after itself. – gWaldo Aug 14 '12 at 15:15
Unfortunately the physical capacity does not yet allow for dynamic environment allocation, and I have not been her long enough to automate provisioning to that level of awesomeness. – gWaldo Aug 14 '12 at 15:16
@gWaldo I totally concur. It takes time to get to that level of awesomeness. Regardless though I can still see valid reasons for additional environments, but IMO they would be temporary in nature, exceptions to the norm type of stuff. Hope that helps. – Brent Pabst Aug 14 '12 at 15:19
Maybe your question should have focused around how to work with development managers to control disparity amongst their multiple environments. If its as bad is it sounds your dev managers are out of touch with the physical implications of their decisions. – Brent Pabst Aug 14 '12 at 15:21
I think that you may be right that perhaps I should refocus or reframe the question. Further talks with the dev managers indicate that synonyms vs realities may be causing conflict. – gWaldo Aug 14 '12 at 16:01

I wouldn't necessarily call this 'sprawl', since it looks like you are missing a QA environment.

Development -> QA -> Staging -> Production

is another workflow you could go with.

Development and QA could be internal development and management environment, while Staging and Production could be client facing.


You might want to look into having a maximum of 4 environments, and strict access controls on who can deploy to which environment (to prevent heart attacks). If management starts asking for beta or pre-beta etc. environments, send them to QA or Staging and tell them it's the 'beta' environment.

I think locking down the access will help control the sprawl. If you are running a CI server, you could limit deployment to production by putting a password field in your build job configuration and having your build script check against a password hard coded into the script. i.e.:

if [ $PASSWORD == 'foo' ]
 exit 1;

Yes, it's a total hack and faux security, but it has the psychological effect of keeping people from deploying to production higgledy-piggledy and instead staying with the environments that are easiest to deploy to.

share|improve this answer
No, no, I'm saying that Dev-Stage-Prod is normal. QA is fine, but I keep hearing excuses for adding more and more. – gWaldo Aug 14 '12 at 15:05
@gWaldo Who's making the excuses/request for more environments? Development or Management? – CamelBlues Aug 14 '12 at 15:10
It seems to be the Developers claiming environments. "I only deployed to half of the prod environment because those are the pre-prod servers..." (This is where I have a heart-attack.) – gWaldo Aug 14 '12 at 15:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.