When I deploy a website to a server (DEV, QA, STAGE and PROD) I create a new folder
WebSite-YYYY-MM-DD
and then I deploy the files to that folder. When everything is all set, I copy in the specific configs for the environment. Once I’m ready, I open IIS and change the site’s path to use the newly created deployment folder.
If anything is wrong, I just point IIS back to the previous folder.
Benefits:
- Allows the setup of a new deployment without taking the site offline
or putting it in an invalid state. - Fast switch over
- Easy rollback
- Easy to use versioning
- Don’t have to fight with locked assemblies
Con:
- Doesn’t work this way when using a continuous integration/automatic
deployment setup
Is this is a good method for deployment? I’m trying to convince my team to move away from creating zip files of the existing folder then copying over the existing files.
Cons:
- You don’t know when the current deployment was released so the
versioning isn’t accurate (I suppose this can easily be worked around
by using integers instead of dates) - Have to deal with locked files
- The site is in an unstable state until deployment is done
- Have to wait for zip/unzip when deploying/rollback
- May have to reset site to force usage of new assemblies
My focus is on a fast/accurate rollback when something goes wrong and an easy to use and accurate versioning system
The other issue you can run into is that if your simply ziping and then copying over files it would be leaving behind old files that are no longer needed. You would need to zip, clear directory (can take time and interrupt site operations) and then copy your new files over (more down time while moving)
All in all your solution is a good one provided that you remember to go back and archive or delete old files.