If I can get root access, I’ll use version control for deployment as
well… It beats ftp and scp hands down for speed. Setting up a
repository on a remote server means I get automatic off-site backup as
part of the development cycle, and deployment/site update is as simple
as a three word command line entry. Small changes on remote test sites
can be made with Vim (or your *nix editor of choice), and checked back
in to the project. If there is a problem caused by the difference
between the development and test environments, it can be quite a little
time-saver.
I am curious though… Does anyone else do this? I haven’t come across
any (I only started doing it recently), but can you think of any
potential disadvantages? Do you have any better or alternative
deployment techniques for Rails projects?
Ben
On 12 May 2006, at 10:45, DJ Tequila wrote:
I am curious though… Does anyone else do this? I haven’t come
across any (I only started doing it recently), but can you think of
any potential disadvantages? Do you have any better or alternative
deployment techniques for Rails projects?
If you don’t use capistrano yet, start using it now! 
http://manuals.rubyonrails.com/read/chapter/97
Cheers,
Chris
DJ Tequila wrote:
I am curious though… Does anyone else do this? I haven’t come across
any (I only started doing it recently), but can you think of any
potential disadvantages? Do you have any better or alternative
deployment techniques for Rails projects?
That’s pretty much how Capistrano works 
I have to chime in and agree. Capistrano (the software formerly known
as SwitchTower) is brilliant. It only took me about an hour to learn
how it works, but the actual setup process only takes minutes. It
basically makes deploying a new release as simple as “rake deploy”.
Broken release? “rake rollback”.
Ken
so do most of you guys use Capistrano in addition to your version
control system, such as svn? I use svn for all my development, and
when it comes to deployment time, I had planned on using svn on the
server and just doing an svn co/update to bring the server sources in
line with the development sources… I thought Capistrano was for
people who didn’t use some type of version control management
software…
Mike
AFAIK, Capistrano requires some kind of version control to work at all,
at least to do anything useful.
(what kind of developers don’t use version control anyways?)
On 5/12/06, DJ Tequila [email protected] wrote:
I am curious though… Does anyone else do this? I haven’t come across
any (I only started doing it recently), but can you think of any
potential disadvantages? Do you have any better or alternative
deployment techniques for Rails projects?
Ben
I’m doing that with Darcs. Very simple: a one-line “darcs push”
command that I’ve set as a script. So my deployment is basically:
deploy_script
and enter. But, reading this thread, I guess I should indeed check
Capistrano (which was recommended to me several times).
If all Capistrano did was simply update source code on your server, then
it wouldn’t be that useful compared to the approach you describe.
However, it does a whole lot more. It can deploy code simultaneously
across many servers in a farm. It’s also super easy to define
additional actions to take as part of your deployment process (e.g. do a
database dump, migrate your database, bounce your servers, copy files,
rename directories, etc.) You can even define a sequence of tasks in a
“transaction”, so if one task fails, Capistrano will automatically
execute the “rollback” task. Lots more good stuff too.
Mike C. has blogged a nice summary of it here:
http://clarkware.com/cgi/blosxom/2005/12/17
Ken