I added
Capistrano to the mix yesterday evening, and it's definitely nice being able to type "cap deploy" and have the latest version of the website checked out from subversion + app-server restarted automatically. It might be slightly overkill for out situation, which is a single httpd, single app-server instance (passenger) and a single database, and all running on the same system... but it does automate stuff, and should the system ever need to scale, you can simply add more servers and update the deployment script.
Took a slight bit of work to get up and running, especially since I had my subversion repository running through svn:// - I started by moving that to svn+ssh:// , which required changing a few things here and there. Upside: my svn setup is now pretty secure, and it's not too bad adding new users - their pubkey (and some SSH tunnel command-overriding magic) in ~subversion/.ssh/authorized_keys. I've wanted to do this for a while, but never got around to it, especially not after deciding to switch over to git. My two classmates insisted on svn for this project, so here we are
I also got the time to look into SSH agent-forwarding, which is neeeeeeeeato. I've normally only SSH'ed into one box, but when SSH'ing to another box, or scp'ing or svn+ssh'ing back and forth between systems, it
really simplifies things - and is a lot more secure than keeping your private keys (or, *shudder*, plaintext passphrases) on involved machines along the route.
Anyway, the default simple Capistrano deployment procedure documented on their site
sucks - it's slow and
INSECURE. I didn't realize this until I started wondering why the /var/www/ourapp/releases/* folders were so huge. I realized that they had .svn subfolders... yes, that's right, not only does the default Capistrano setup pull your FULL set of sources from your repository on every deploy, it does a CHECKOUT rather than an EXPORT. This means people can access
http://joor.0wned.org/.svn/* files, which leaks information. Oops.
Solution: install the
capistrano_rsync_with_remote_cache gem, which does
svn checkout (and after that,
svn update) to a
.rsync_cache folder on the machine you're running the deployment script from, and then does rsync to the servers you're deploying to. This part fixes the slowness, by only transferring the modifications to the server. This STILL transfers the .svn folders, though, until you add the following line to your deployment config file: "
set :rsync_options, '-az --delete --exclude=.svn --delete-excluded'" - presto, fast and
safe deploys.
It scares me a bit that the defaults are so
retarded, and that there's no mention of this on the main site...
google was very helpful once I discovered the .svn folders, though, and it took around 20 minutes from beginning researching the problem until the fix was in place and tested
Recent Posts
).
. The admin interface is definitely pretty comfortable.
(it's possible to write decent stuff in PHP, but there's ugly stuff in the language, and the standard library is a complete messy hackjob).