Managing site deployments between demo/staging/live on production servers

Question

The way we currently manage site roll outs to the server and then switching sites between demo/acc/live "mode" is a bit hap-hazard and i'm looking to improve the whole process.

I've been reviewing automated deployment tools, but also the way the server is structured. I'll save the automated deployment questions for another post, here i'm interested in how people organise code on their production servers.

We currently have 3 top level folders on the data drive, "demo", "acceptance" and "live". There's tenuous differences between what classifies something as "demo" or "acc" which i won't go into, suffice to say i want to be rid of all argument/ambiguity.

Our rollout procedure is as follows, once a site is developed, roll it out under an "acceptance" host header such as acceptance.project-domain.com under the "acceptance" folder. The client reviews the site, we give it a test to make sure all connection strings/permissions etc are correct. The client gives the OK to go live. At this point, we completely re-roll out the site under the "live" folder and give it the live host header. of course at this point the site is totally untested in its deployed state (not talking about unit tests here, i mean file permissions, iis setup mistakes etc). The site then has to be re-tested :(

I think a structure something like this, would be much better:

/<customer>/<project>/<fullversion>/wwwroot

This way, a new site can be rolled out to a version1 folder under an "acc" host header. If the client gives the OK, you simply switch the headers and youre away. If there are change requsts, they go under a v1.1 which can have the acceptance header, once it gets the ok, swap the headers and youre good. Rinse and repeat.

This process would also be much easier to manage for an automated deployment script. Having all the code for a site under a single parent folder means upload permissions can be restricted to a single site, so you cant accidentally overwrite another site's code, its much easier to keep a track of what versions there are on the server, the project management wiki can easily be maintained... the list goes on!

What are your methods of code organisation and rollout management?

Answer 1

Most people don't operate in the way you've proposed because they use separate servers for test and live.

We have stripped all configuration out of our projects, so we can deploy exactly the same code to the test and live machines and they will automatically pick up the correct config. This prevents unexpected "oops I'm pointing at test instead of live" moments.

Your idea may well work - but what if you do decide to split your servers up in the future (you can't exactly run performance testing against it if it could potentially impact your live websites for example).