Capistrano: update instead of checkout?

Rails
1

Hello,

Just started to use Capistrano for deployment and everything works
beautifully
and as advertised. Thanks Jamis for this great piece of software.

However, in my case, the deploy task takes quite some time since my SVN
repository resides on a different continent than my app/db server and
I’ve
frozen all the rails code in the vendor dir and checked in. All in all
my app
sums up to about 40M. The svn checkout of the code takes about 5
minutes. That’s no big deal for regular deployments of new versions of
the
application.

But of course there will be a typo somewhere in the app side of my newly
deployed site. Fixing it is easy, deployment too - but compared to the
time I
needed to correct the error, deployment takes far too long. Furthermore
I mind
the spoiled bandwith - transferring 40M just because one letter changed
is
not really gentle. The sideeffect of this: I postpone the deployment of
minor
and uncritical bugfixes. And that’s an attitude I doesn’t like either
:slight_smile:

I guess I could customize the Capistrano update_code recipe so that it
performs a

  1. copy -r <old_revision> <new_revision>
  2. svn update <new_revision>

(given that the <old_revision> is a checkout and not a svn export, of
course)

Somehow sounds too easy …

My question therefore: can somebody tell me why this would be a bad
thing to
do? If it would be so easy and without drawbacks, why isn’t it the
default
behaviour of Capistrano then? What am I missing?

Thanks a lot & regards
Thomas

2

On 5/19/06, Thomas W. [email protected] wrote:

My question therefore: can somebody tell me why this would be a bad thing to
do? If it would be so easy and without drawbacks, why isn’t it the default
behaviour of Capistrano then? What am I missing?

A better question is why do you have 40 MB of source code for a
website? If this is mostly images, you could have those in the shared
directory and deploy only the source code via your default Capistrano
task.

– James

3

James L. <jamesludlow@…> writes:

A better question is why do you have 40 MB of source code for a
website? If this is mostly images, you could have those in the shared
directory and deploy only the source code via your default Capistrano
task.

As I said: I’ve checked in rails and a bunch of plugins:
% du -sh vendor/
32M vendor

All the image data already resides in public/system and is linked to
shared
therefore.

Of course one could argue to put some of the vendor stuff to shared,
too. But
that makes the whole thing complicated. And simplicity is the reason why
Capistrano itself deploys everything to app, db and web although not
everything
is needed everywhere. If I get efficiency “for free” in just using
update
instead of checkout, that’s certainly the path I would prefer.

But thanks for your suggestion anyway!

4

Thomas W. wrote:

…The sideeffect of this: I postpone the deployment of
minor
and uncritical bugfixes. And that’s an attitude I doesn’t like either
:slight_smile:

I guess I could customize the Capistrano update_code recipe so that it
performs a

  1. copy -r <old_revision> <new_revision>
  2. svn update <new_revision>

(given that the <old_revision> is a checkout and not a svn export, of
course)

Somehow sounds too easy …

For minor revisions, why not just ssh to your server, change to the
appropriate directory, and “svn update”?

I don’t see why your proposed change wouldn’t work, but doing it
manually might be just as easy.

–Al Evans

5

On 19 May 2006, at 19:08, Thomas W. wrote:

32M vendor
You can use the following tip to help manage your vendor/rails.
http://rails.techno-weenie.net/tip/2006/2/7/
deploy_your_apps_on_edge_rails

is needed everywhere. If I get efficiency “for free” in just using
update
instead of checkout, that’s certainly the path I would prefer.

But thanks for your suggestion anyway!

I set up a system similar to the vendor/rails tip for the actual
source of an app for a client. It’s checked out to the deployment
machines once, and only updated from then on as there’s a lot of
source which is uploaded over a pretty slow adsl line. I wouldn’t do
it in all cases, but it made sense here.

Chris

6

Al Evans <anejr@…> writes:

manually might be just as easy.
Good point. It’s even easier, as I noticed when looking closer at
Capistrano:
There is already a remote:update_current task labelled “Update the
currently
released version of the software directly via an SCM update operation”.
It’s not
documented in the manual so I missed it the first time.

Thanks a lot for your reply!

–Thomas

7

This might help, I didn’t want to store a rails version in svn or to
make
my deployment dependent on the rails site being up. Therefore, I
checked
out rails 1.1.1, and created a directory called rel_1-1-1 under my home
directory. Then I created this simple task below to create a symlink
whenever it is deploying. I placed this code into the deploy.rb file.

desc “Symlink Rails to version 1.1”
task :after_symlink, :roles => :web do
run “ln -s ~/rails/rel_1-1-1/ #{release_path}/vendor/rails”
end

You would need to remove rails from your svn setup. Also, if you deploy
5
times and don’t clean out the old ones then you are using 200MB of disk
space. With this method you would only be using a fraction of that
amount
of space, and it will finish much quicker!

Hope this helps!