Home / server / Questions / 417395
Accepted
gWaldo
Asked: 2012-08-15 06:58:47 +0800 CST

Development Environment Sprawl

  • 772
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...

configuration

2 Answers

  1. Best Answer

    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.

    • 1

  2. 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.

    [edit]

    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' ]
 build_app();
else
 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.

    • 0