Probably the simplest solution is to start up another instance of your 
updated application listening on a different port, look for errors on 
STDERR, and test it using a web browser. Then you're less likely to kill 
the main site when you roll it out.

> The app is a Ramaze app in case that's relevant.

Yes I'd say it's relevant.

Rails has a mechanism by which you can declare all the gems used (and 
versions, if necessary); then there's a rake task to install any missing 
gems on the target server. However this does rely on you recording all 
the gems used. Maybe there's an equivalent plugin for Ramaze.

A sledgehammer approach is to "vendorize" all the gems your application 
uses - that is, stick them in a vendor/ subdirectory or whatever. Then 
as long as you don't do 'require "rubygems"' anywhere, then you know for 
sure that all the libs you require have been vendorized. (Probably only 
works for 1.8, since 1.9 includes rubygems by default I believe)

If you're developing with git, then you can include all the libraries as 
git submodules. Then on the target system:

git pull
git submodule update

will update both your application and the vendorized libraries. This has 
the advantage that you can choose any particular revision from each 
library that you like - you're not restricted to officially released gem 
versions. However it does rely on the libraries you use being available 
from git repos.

Some care is needed when adding, updating or removing submodules in git.

HTH,

Brian.
-- 
Posted via http://www.ruby-forum.com/.