How much should the staging environment equal the live one?

Question

Management has decided to go for Windows 2008 64 bit with IIS7 to service our main website.

They want to have it staged on a Windows 2003 server with IIS6.　[Edit] Yes 32 bit is what they are planning for staging [End Edit]

I want to know what issues, beyond the security issues, that I should put forward, suggesting we should opt for the same server in staging as in the live environment.

I have read great posts like this, but I want something I can say with a few bullet points

That staging and live environments should be the same, is easy for any seasoned developer to understand, my problem is that I am trying to explain this to upper level management people who seem to have already made up their mind...

---

[Edit] @Luke:

Its basically a website which gets updated quite often, the whole site is to be staged, tested, before deploying to the live environment.

The site is to be left at the hands of the Marketing department, (non developers) and have them verify that the site has no issues before deployment.

---

[Edit++] Code is ASP.NET, used in 3 important customer ordering pages.

Thanks,

Ric

Answer 1

The more the staging environment matches live, the more issues can be found in test. If you have only a poor match, like what you have here, this limits the kind of bugs might be uncovered. For example, suppose there is an incompatibility with 2008 64bit and some component of the site? You will not find it until you have gone live. This could be too late.

Answer 2

I hope thats not a 32-bit Windows 2003 staging server you're using to test functionality for a 64-bit Windows 2008 production server or you are in for a world of pain.

The staging server should be, as far as possible, the equivalent of the production server because what you are using it for is to answer the question "Does this software work on the production environment?" before actually committing to loading it on the production environment.

Answering the question "Does this software work on a server that is almost totally unlike our production server?" is not useful and in reality all you are doing is committing to testing and debugging the software in yet another environment, but in an environment that you won't actually use. Its more work and in the end you still don't know if it works on your production environment, which is the entire point of having a staging server in the first place.

Answer 3

Preferably live and staging should be the same technologies of course (same box?). But what are you staging here, technology or content? If the staging environment is mainly for content then you might get away with both servers not being the same. However, if you're staging technology then you will definitely run into issues where you put stuff live that doesn't work properly. I guess, if the guy with the wallet is willing to be responsible for that, go ahead...

Answer 4

Explain it to the business in terms of risk and money.

• The risk of your site encountering issues upon production deploy is known and non-trivial.
• The cost of your site going down because of an unforeseen issue is extremely high.
• The potential cost of the time it takes your support staff and developers to pinpoint issues each time they're encountered in production because your staging environment isn't answering the right question ("Will my software work in production?") is high, and exacerbates the former.
• The late nights and high stress levels repeated failed deployments can incur will lead to an unhappy, unproductive team, which can lead to unacceptably high turnover rates.
• The cost of mitigating all of this via the purchase of hardware is relatively low, and many reputable engineers recommend it as a best practice.

Answer 5

Perhaps you should ask them what they believe a staging environment is. Explain to them that the entire point of a staging environment is to mimic the production environment as well as possible. Explain that if the staging environment is to be drastically different, you might as well not have it. Then if you do not have it, your production site will be used for testing. Tell them that it's really not that big of a deal, just that the site will break a couple times, and possibly have some major security leaks before you get everything fixed due to the lack of proper staging. I'm sure they'll understand.

Answer 6

The general rule is that you can only validate changes that use common subsystems between stage and live. If you are only validating HTML copy changes, and can guarantee that only HTML is being rolled from stage to live, it will probably give you high confidence that the site will work on live.

You have so many differences between stage and live that you can not validate any coding or IIS configuration changes. It will be "push and pray" going to live.