Manage site deployments between demo / staging / live on production servers
The way we currently manage the site uploading and then switching sites between demo / acc / live mode is a little dangerous and I want to improve the whole process.
I looked at the automated deployment tools as well as how to structure the server. I'll save the auto-deployment questions for another post, here I am interested in how people organize code on their production servers.
We currently have 3 top-level folders on the data disk, "demo", "accept" and "live". There are minor differences between what classifies something as "demo" or "acc", which I won't go into, suffice it to say that I want to get rid of all the arguments / ambiguity.
Our deployment procedure is as follows, once the site has been developed, deploy it under the host header of the host, for example, acceptance.project-domain.com
in the folder "receive". The client browses the site, we give him a test to make sure all the connection strings / permissions, etc. Are correct. The client gives OK to go live. In this step, we will completely flip the site under the live folder and pass the host header to it. of course the site is completely untested at this point in its deployed state (not to mention unit tests here, I mean file permissions, iis setup errors, etc.). Then the site needs to be re-tested :(
I think a structure like this would be much better:
/<customer>/<project>/<fullversion>/wwwroot
This way the new site can be moved to a folder version1
under the host header "acc". If the client says OK, you just switch the headings and you're gone. If there are change requirements, they fall under v1.1
that can have an accept header, as soon as it's ok, swap headers and you're good to go. Rinse and repeat.
This process will also be much easier to manage for automated script deployment. Having all the code for a site under one parent folder means that download permissions can be limited to one site, so you can't accidentally overwrite other site code, it's much easier to keep track of which versions exist on the server, the management wiki project can be easily saved ... the list goes on!
What are your methods of organizing your code and managing your deployment?
source to share
Most people don't work the way you suggested because they use separate servers for testing and live.
We removed all configuration from our projects, so we can deploy the exact same code to test and live machines, and they will automatically pick up the correct config. This prevents unexpected "oops I'm point on test instead of live" moments.
Your idea might work well, but what if you decide to split servers in the future (you can't accurately perform performance testing against it if it could potentially affect your websites, for example).
source to share