Rails - May 2006 - Capistrano: update instead of checkout?

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 :-)

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

On 5/19/06, Thomas Werschlein <werschlein@interlace.ch>
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

James Ludlow <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!

Thomas Werschlein wrote:
> ...The sideeffect of this: I postpone the deployment of 
> minor
> and uncritical bugfixes. And that''s an attitude I doesn''t
like either
> :-)
> 
> 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



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

On 19 May 2006, at 19:08, Thomas Werschlein wrote:
> James Ludlow <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
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

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

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!


On 5/20/06, Chris McGrath <chris@octopod.info>
wrote:
>
> On 19 May 2006, at 19:08, Thomas Werschlein wrote:
>
> > James Ludlow <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
>
> 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
>
>
> > 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!
> >
>
> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060521/1eef55f4/attachment.html

Al Evans <anejr@...> writes:
> Thomas Werschlein wrote:
> > 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>
>
> 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.
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