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 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.