Installing dev tools in production

Question

What are the reasons for not installing VS 2008 on a live production web server?

Answer 1

No reason, other than disk space, and perhaps a wasted license, why not? However, what are the reasons for installing VS 2008 on a live production web server? You can debug remotely, if you have some bug you just can't duplicate in you dev or test environment, and really have to do debug it live. So I can't think of any reason to do it.

Answer 2

Given the comment the OP made giving a reason why you would do this:

Would make "works on my machine" issues easier to debug

Then my answer for why it should not be installed is: to remove the temptation to try and debug problems on the live production Web server.

Answer 3

I can think of a few:

• Development should not occur on a production server.

Development and testing of programs should always occur on a development server. The development products are then deployed to the production server. Developing on a production server runs the risk of crashing the production server.

• Only production software should be installed on a production server

Development software contains components that complicate the operating environment of a production server. There can be DLL versioning issues, for example. In general, the production server should only contain the software it needs to do its job.

• Having development (or other) tools on a production server encourages uses that the production server is not purposed for.

Maybe you are considering installing VS 2008 for convenience. It is nice to have the tools at your fingertips. But how easy is it now to cut corners, and fix something on your server on the fly without following your software development process?

Answer 4

The biggest reason for not installing it:

It would mean you were not doing an incredibly silly thing on your production server.

If you cannot replicate issues in code on your development machines then you need to create a staging server that exactly replicates the configuration and environment of your production environment. If you still can't replicate the fault on that, it means you have either a: failed to replicate the environment well enough, b: do not understand your configuration on your production environment well enough to be able to replicate it or c: have not properly configured your application to deal with the change in environment.

Another reason:

You don't have to have a copy of your source-code on your server and the ability to easily compile it in place. If you ever get hacked, you'll be glad you didn't do that as your source code will get stolen and/or the hacker will have an extremely easy way to insert malicious code into your app.

Answer 5

If you have enough licenses and if the team is disciplined, I wonder why you cannot do that.

Answer 6

I concur with some of the posts that explicitly states that you should neither be doing development nor debugging on production. If an error should occur, ensure that you have a procedure in place to log the necessary data.

If any issues should occur while deploying new code, revert back to the old one and use the (exception)data to troubleshoot the code back in your development or your staging machine.

The production server should only have the bare bones software required for it to fulfill its role. Installing a full blown IDE on it seems too heavy. It will also raise the question on whether you need to update the IDE once an SP is released? What if the installation went wrong? All these are issues which could be easily avoided by not installing VS on the server.

The lesser things there are on your production server, the lesser the likelihood of things going wrong.