I've always used a very simple bash script to deploy code. I'm moving away from using subversion to Mercurial but I don't really think the revision control software matters for deployment.
What are some betters ways to do this?
#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
I use Mercurial to manage everything, including my static HTML pages. It makes life really, really easy for me.
Benefits include
Disclaimer, I wrote the tutorial. Yes, the kind of VCS you use does matter, to a degree. For instance, I would not use something in this scenario where I could not commit locally and make one big push / update. That just forces me to lump too many potentially problematic changes into one commitment.
I could do it with Subversion, and I'm not knocking SVN at all. I just think Mercurial is a far better tool for the problem you are trying to solve.
Its my opinion that you should not have to 'work around' your tools unless you have no other choice. Doing so sort of defeats the purpose of having them, and you do have a choice :)
In addition to the excellent suggestions in the other answers, you may want to consider whether it is important to you to do an atomic update.
On my FreeBSD server, I accomplish this through two mechanisms:
Versioning all of my static resources. (E.g. http://static.example.com/images/logo.1.png or http://static.example.com/style/main.3.css ). This allows me to svn update the static site directly prior to updating the dynamic site, without worrying about users seeing new files in old pages.
Versioning the entire dynamic website. In my case, I have my document root pointing to a symbolic link. My strategy is to get the new version of production in place and then with a single command push it live. .g. something like this:
cp -Rp www.site1.com.1 www.site1.com.2 (or svn checkout)
svn update site1.com.2 (may need an svn switch first)
ln -sf site1.com.2 www.site1.com (atomically move changes to production)
This ensures that none of my users end up seeing a half-baked page. They'll either see the old version if it's still in their cache, or the new one.
This strategy only works well if you aren't mixing user-uploaded content with your dynamic site.
We use ant's scp task, with the modified selector. That means you just update the files that have changed since the previous upload. Unfortunately, the modified selector seems to be designed only for personal use, not sharing with team members. The cache.properties file has path names to the user's working directory in it. We wrote a bunch of ant targets to massage the cache.properties file into a format that can be shared between developers and then massaged back into the format that ant needs. The format also varies between a Windows environment and a GNU/Linux environment.
Isn't the whole point of using version control that you don't need to concern yourself with backing up the site before pushing out an update?
If it's done correctly, an svn update (or equivalent) should be enough, and if it's a mistake then roll it back to a previous commit? That's what we do anyhow. Commit all the changes, svn update the staging server, if it's all OK then svn update the live server.
