Sillyness, werd

Deploying web apps with SVN

I sat in an interview today where the interviewee lamented the lack of a clearly laid out tutorial on how to deploy web applications with SVN.

Since this is exactly what we do at $work, I thought I would try my hand at hammering something out here. In this little diddy we will cover the the uses of trunk and tags. Also, please understand this is how we do it, not The One True Way^TM.

Here are the terms I will be using, and what I mean when I type them:

1. Trunk is used for active development. There is never a guarantee that trunk will be stable.
2. Tags are snapshots of a moment in time. Each “release” of your web app corresponds to a tag. Bug fixes and small feature additions will be applied to tags, but nothing significant.

First, we need to get an svn checkout running on our public site

This is the easiest part, given a few assumptions:

1. You have SVN installed on your webserver
2. You have a stable tag of your software to deploy

If these two facts are true, then here is the process you would follow to run your site out of an SVN tag checkout. First let’s connect to the web server:

ssh www.mysite.com -l chrisjdavis

Next we need to change to the web root directory. This is determined in the httpd.conf file of your server (Look for DocumentRoot):

cd /www/vhosts/

Now, we need to get a checkout of the latest tag:

svn co http://svn.mysite.com/www/tags/4.1/htdocs www.mysite.com

What that command says is that we want to grab the htdocs folder in the 4.1 tag and place it on our server, but rename htdocs to www.mysite.com. If you didn’t need/want to rename the folder you could simply replace www.mysite.com with a period.

At this point you should have a full checkout of your webapp. Everything is now ponies and rainbows. Unless of course, you find out there is a typo in your form class. Now you need to fix the bug, and get that change to your live site is the least destructive way.

Okay, now how do we update our site?

Alright, here is the process from beginning to end, in rapid succession!

Your live site, in this case www.mysite.com, is a checkout of the latest released tag which we identified earlier as 4.1. You find that there is a typo in your form class, so you need to fix that bug so that your users can get back to creating email forms.

Your first step is to fix the bug in your checkout of trunk. Once you have the bug squashed and thoroughly tested you:

svn commit /www/trunk/htdocs/includes/classes/form.php -m "Stupid typo's. if( $foo == $bar), not if($foo = $bar)"

This will send your local changes to the SVN server. Once the commit is done and you get back the revision number, let’s say 8859, it is time to port this fix to the currently active tag by cd’ing to the tag and issuing the following:

svn merge -r 8858:8859 http://svn.mysite.com/www/trunk/htdocs

What this says is take any changes that happened between 8858 and 8859 from trunk on the remote server and merge them into the tag you are currently in. Watch your output while the merge is happening. You want to see U, G and A codes come through, not C. C means conflict. This is bad juju.

Assuming you didn’t get any C’s it is now time to commit these newly merged changes into the tag on the SVN server:

svn commit /www/tags/4.1/htdocs/includes/classes/form.php -m "Stupid typo's. if( $foo == $bar), not if($foo = $bar)"

Once this commit runs, it is time to update your live site with the newly fixed code:

ssh www.mysite.com -l chrisjdavis

cd /www/vhosts/www.mysite.com/

svn up includes/classes/form.php

At this point if you don’t see any C’s go flying by, you should now have a fully updated checkout of the 4.1 tag complete with your bug fix from trunk.

Pretty simple really and very, very fast.

If you have any questions, let me know in the comments.