I am in the process of migrating several rails apps from a single server
that runs nginx, mongrel, and mysql to separate (virtual) servers and am
wondering if I am, perhaps, overthinking my new deployment strategy. I
am using Capistrano 2.1, btw…
What I would prefer is for the app tree to be deployed such that the
rails app stuff is only on the vm running the mongrels, the static files
would go to the nginx server (which is proxying to the rails backend)
and no files would get put on the mysql server… but this leaves me
with a few questions 
Is it safe to omit the public folder when publishing to the app role?
Are there other folders in my rails app tree I can omit during
deployment to production (like test…)?
Is there an easier way to exclude files/folders from being deployed to a
role than just sending them and then deleting them? I am using the
copy+tgz strategy to update code to avoid the need for scm utils on the
production servers.
Thanks for any suggestions…
Tim F. wrote:
I am in the process of migrating several rails apps from a single server
that runs nginx, mongrel, and mysql to separate (virtual) servers and am
wondering if I am, perhaps, overthinking my new deployment strategy. I
am using Capistrano 2.1, btw…
okay. I did the same thing, first rev of application was all on one,
and second one was on seperate virtual servers, such that I could move
them to additional hardware and/or add mongrel cluster machines.
What I would prefer is for the app tree to be deployed such that the
rails app stuff is only on the vm running the mongrels, the static files
would go to the nginx server (which is proxying to the rails backend)
and no files would get put on the mysql server… but this leaves me
with a few questions 
so, cap does not seem to do this. I just lived with the fact that my
ruby code exists on my web server, such that /public gets pushed out. Oh
well.
I didn’t install mongrel or ruby on that machine, and it has no
database passwords…
Is there an easier way to exclude files/folders from being deployed to a
role than just sending them and then deleting them? I am using the
copy+tgz strategy to update code to avoid the need for scm utils on the
production servers.
I also realized that installing all of ruby/gem/etc. on my database
server was silly. So, I don’t list my database server role. The machine
marked as the “db” role is the one which will run the migrations.
Jamis B. wrote:
On Jul 14, 2008, at 9:50 AM, Michael R. wrote:
Note that cap can do that…but you would need to write the tasks to
do it. The default deployment tasks are just opinions codified, and as
such only satisfy the majority of cases, but not all. Cap itself,
though, can be scripted to support a much larger set of deployment
scenarios.
Thanks Jamis … the thing I find a bit difficult to get my head around
is exactly which tasks are executed on which roles in the default
tasks… Is this documented somewhere?
Also, I currently have in place is a few custom tasks that replace
certain default tasks and then replacement tasks for the cold_deploy and
deploy tasks that incorporate my custom tasks in the process where I
need them. Is there an easier or better way to override defaults or is
that the way it should/must be done?
Cheers,
Tim
On Jul 14, 2008, at 9:50 AM, Michael R. wrote:
well.
I didn’t install mongrel or ruby on that machine, and it has no
database passwords…
Note that cap can do that…but you would need to write the tasks to
do it. The default deployment tasks are just opinions codified, and as
such only satisfy the majority of cases, but not all. Cap itself,
though, can be scripted to support a much larger set of deployment
scenarios.
On Jul 14, 2008, at 10:18 AM, Tim F. wrote:
Thanks Jamis … the thing I find a bit difficult to get my head
around
is exactly which tasks are executed on which roles in the default
tasks… Is this documented somewhere?
Alas, no. I’d recommend reading the capistrano/recipes/deploy.rb file,
as it is pretty well documented and not as magical as most people seem
to fear. (Not magical at all, really.)
http://github.com/jamis/capistrano/tree/master/lib/capistrano/recipes/deploy.rb
Also, I currently have in place is a few custom tasks that replace
certain default tasks and then replacement tasks for the cold_deploy
and
deploy tasks that incorporate my custom tasks in the process where I
need them. Is there an easier or better way to override defaults or is
that the way it should/must be done?
You’ve got it right. When you need to change the behavior of one of
the “meta” tasks (like deploy:cold or deploy), you basically need to
do like you did, and rewrite it.
