Environment tiers, from development to deployment - what works best?

Question

So I do development for in-house web apps, C#. We've always had a problem with developers tripping over each other since we typically don't set up more than a shared "development" environment and a "production" environment. I want to end that, 'course, but would like some feedback on how to do it. What's the best way you've found to develop, integrate, test, and deploy your applications? This is a Microsoft environment, but of course general advice is helpful.

I'm thinking...Windows Server 2008, Hyper-V'ed desktop machine to run local dev environments, then maybe a beefier server for virtualizing a staging tier (basically integration of developers' code together), a testing tier (for our end users to poke around on after some internally-tested code), and then the production tier. Has a four-tiered solution like this worked well? Is virtualizing that much a good idea?

Answer 1

What I usually recommend when setting up a shop to be more careful about this stuff is the following:

1. Developer workstations for writing the code.
2. A dev server. This is for seeing whether code will work off of a workstation.
3. A test server for business and user testing. This should be configured fairly closely to the production setup.
4. A staging server. This should be 100% identical to your production environment if at all possible. The purpose of the staging server is not to test whether your code works or whether the users will be OK with your changes. It is only there to test whether the actual deployment to production is going to work properly or not and to do things like load testing. Staging is about simulating your production environment and avoiding surprises when you go live.

I'd virtualize the dev and testing servers and possibly the workstations, but not the staging server unless you'll be virtualizing the production one as well. From what I've heard, msdn.microsoft.com is largely hosted on virtual servers at this point.

Answer 2

While I would love to build an environment like that where I work, we are currently stuck doing all our development/staging/testing on our production server. We obviously have a long road ahead of us...

One thing I have found that works well is for each developer to have their own development VM so that they're not running over each other while coding. I typically run on Linux servers so the footprint of the VM is a fair bit smaller, but that doesn't really change things. I have generally found that there is usually little need for separate staging/testing machines since they don't tend to do much.

Answer 3

At my job, we have three machines (plus developer workstations): build server, development server, and production server. This works well (as long as you don't give the worker bees the URL to the development server).

The build server runs CVS and (unfortunately) NANT in a continuous integration setup. Changes get deployed to the development server once a day (or so), and live there until they're run through, then get integrated with the application on the production server. Normal, day-to-day testing is done on dev machines.

Answer 4

We have a dev server, continuous integration pumping it on every check in and running test. And once the customer approves its stability, we branch and build. Staging is omitted at this point, but I would recommend it also. We are just looking for pace and keeping our code production ready, by the end of every iteration.

The missing link to keep us all on the same page, was CCNet, it allows us to deploy, and run unit tests automated, so that when things go good, we can deploy to production with the click of a button.