deploy:cold without migrating db

[Lucas]

The database in my RoR application is shared with a 2nd application,
and created by the latter, so I need capistrano (cap deploy:cold) to
assume the database is there and ready to use already, instead of
trying to run all migrations. Is there a way? Should I create an extra
task?

thanks

[Rafael G.]

Lucas escribió:

You can overwrite cold task in your deploy.rb file:
namespace :deploy do
desc <<-DESC
Deploys and starts a `cold' application. This is useful if you have
not \
deployed your application before, or if your application is (for some \
other reason) not currently running. It will deploy the code, run any \
pending migrations, and then instead of invoking `deploy:restart',
it will \
invoke `deploy:start' to fire up the application servers.
DESC
task :cold do
update
# migrate # Commented, can be deleted
start
end
end

Regards

--
Rafael Garcia Ortega

[David Masover]

If the second app is a rails app, why should you have any migrations at all?

If it's not, is it possible to create a schema_info table for rails?

And if Rafael is right about deploy:cold, you could always just manually do deploy:update and deploy:start. I know we often have to do a bit of manual work on the first deploy -- there's always a migration somewhere that depends on a plugin that we're no longer using...

[Lucas]

Thanks a lot! =)

[Tim Carey-Smith]

On 7/04/2008, at 11:28 AM, Rafael G. wrote:
>
> You can overwrite cold task in your deploy.rb file:

It would seem to me that you should consider not changing the default
behaviour of the 'deploy:cold' task (even if it is just for this
application).
Having a new task which does the 'deploy:update' and 'deploy:start'
would make it more apparent that you are doing something out of the
ordinary.

In most of the deployments I have done, the 'deploy:start' and
'deploy:restart' do exactly the same thing, that being tell god [1] to
restart the app servers for this application.
What this means is that the 'deploy:cold' and 'deploy:migrations'
tasks are basically the same.

Cheers,
Tim

[Mason Browne]

I would argue that overriding the default tasks is exactly what he
should do. His deployment logic is split between the two projects.
In the first project (which contains the migrations), he'd run `cap
deploy:cold` to get the application kick-started. In his second
project, he wants to skip the migration process, but there's no reason
his cap command should differ for what is essentially the same task -
to kick-start the application.

Overriding the tasks he needs to in this manner has the benefit of
providing a consistent interface to the task of deployment, and hiding
the actual deployment logic in deployment recipes specific to each
application... Encapsulation ftw.

Best,
Mason