Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Some other options you could consider:</p> <p>1) Deploy to a fresh directory each time and then switch between directories using IIS.</p> <p>2) Use a separate Subversion repository for your binaries. svn-load-dirs.pl can load the binaries in to subversion and can correctly mark files that have been added, removed or changed. You can run svn load-dirs on the end of your automated build process. The build process is the only 'user' checking into this repository and the production server is the only place checking it out so there are no versioning conflicts.</p> <p>To deploy you simply svn update the working directory from the binary subversion repository. It efficiently copies down just the changed files in an atomic fashion (i.e. if the download fails it doesn't replace any files). If you find a problem right after deployment you can quickly go back to the previous version. If you want to update a single aspx file you can do a targeted svn update on that single file.</p> <p>If you have TortoiseSVN installed on the server you can also see immediately if anyone has changed any files on the server without going through the correct build->checkin->deploy path.</p> <p>The only caveat is that subversion doesn't handle binary diffs so your repository will grow rapidly, but you can simply wipe it and start again occasionally if that ever becomes a problem.</p> <p>Another plus is that you have a complete record of every version you've ever deployed.</p> <p>I've used this technique for several projects and wish all deployment systems worked more like it: i.e. atomic update, easy to roll back, targeted single file update, complete version history, ...</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload