Geek Answers Handbook

How much should an intermediate environment for living?

The management decided to go to the 64-bit version of Windows 2008 with IIS7 to serve our main website.

They want this to be hosted on a Windows 2003 server with IIS6. [Edit] Yes, 32 bits is what they plan on posting [End of editing]

I want to know what problems, beyond the security problems that I have to offer, inviting us to choose the same server as in a live environment.

I read some great posts like this , but I want something I can say with multiple bullets

This intermediate and living environment should be the same, easy for any experienced developer to understand, my problem is that I'm trying to explain this to top-level managers who seem to have already solved ...

[edit] @Luke:

Basically a website that is frequently updated, the entire site needs to be delivered, tested before deploying it in a live environment.

The site should be left by the marketing department (not the developers) and ask them to verify that the site has no problems before deployment.

[Edit ++] ASP.NET code used in 3 important customer order pages.

Thanks,

Ric

+4
source share
6 answers

I hope this is not the 32-bit Windows 2003 intermediate server that you use to test the functionality for the 64-bit Windows 2008 production server, or you are in a world of pain.

The intermediate server should be, as far as possible, equivalent to the production server, because to use it, it answers the question "Does this software work in a production environment?" before loading into a production environment.

Answering the question "Does this software work on a server that is almost completely different from our production server?" is not useful, and in fact all you do is test and debug the software in yet another environment, but in an environment that you are not actually using. Its a lot of work and, in the end, you still don't know if it works on your production environment, and this is primarily the presence of an intermediate server.

+7
source

The more the intermediate environment works, the more problems can be found in the test. If you have a bad match, for example, what you have here, this limits the errors that can be detected. For example, suppose there is incompatibility with the 64-bit version of 2008 and some site component? You will not find it until you go live. It may be too late.

+3
source

Perhaps you should ask them what they consider to be an intermediate environment. Explain to them that the whole point of the intermediate environment is to simulate the production environment as best as possible. Explain that if the intermediate environment should be very different, you may also not have it. Then, if you do not have it, your production site will be used for testing. Tell them that this is really not such a big deal, just that the site will break a couple of times and may have some major security leaks before you get everything fixed due to a lack of proper setup. I am sure they will understand.

+1
source

The general rule is that you can only check for changes that use common subsystems between the scene and the living. If you only check the changes to the HTML copy and can guarantee that only the HTML will be translated from the scene to the live, this will probably give you high confidence that the site will work live.

You have so many differences between scene and live that you cannot check any changes to the encoding configuration or IIS. It will be a “push and pray" to live.

+1
source

It is desirable that life and staging be the same technology, of course (the same box?). But what are you doing here, technology or content? If the staging environment is primarily for content, you can do without both servers. However, if you are an intermediate technology, you will surely encounter problems when you put live material that does not work properly. I think if the guy with the wallet is ready to answer for this, go on ...

0
source

Explain this to business in terms of risk and money.

  • The risk of your site, which faces problems in the deployment of production, is known and non-trivial.
  • The cost of your site, declining due to an unforeseen problem, is extremely high.
  • The potential cost of time spent by your support staff and developers to identify problems every time they occur in the workplace because your intermediate environment does not answer the right question (“Will my software work in the workplace?”) Is high and exacerbates the first.
  • Lost nights and high levels of stress that can result from failed deployments can lead to an unhappy, unproductive team, which can lead to unacceptably high turnover rates.
  • The cost of mitigating all this by purchasing equipment is relatively low, and many reputable engineers recommend this as best practice.
0
source

More articles:


All Articles