Capistrano/SVN: Deploying different database.yml for live?


#1

Greetings,

Today I’ve been working out how to begin using Capistrano and so far I’m
impressed. Even in my situation, learning Rails and deploying to a
single server, it’s incredibly helpful. I do have one small question
though:

In using Subversion I’ve used the “ignore” feature to ignore my local
database.yml file, because my local database and my live one have
different names.

What should I do to accommodate this in Capistrano? When I use
Capistrano to deploy, the correct database.yml isn’t put into place
where it should be. I’m not sure where to begin to fix this situation.

Thanks,
Jeff


#2

Jeff C.man wrote:

What should I do to accommodate this in Capistrano? When I use
Capistrano to deploy, the correct database.yml isn’t put into place
where it should be. I’m not sure where to begin to fix this situation.

Well you could have two database.yml files named like database.yml.dev
and database.yml.prod and then add a task to link or rename the correct
one on deploy.

But, why don’t you just put all of your database configurations info
into database.yml and select the one that you want to use based on
whether you are in development, testing or production. This is the
standard way to do this in Rails. Just have a look at the database.yml
produced by “rails .”

I realize there may be reasons not to have the production database
password in svn, but this doesn’t seem to be the problem you are having.

Ray


#3

Hello Jeff !

2006/3/29, Jeff C.man removed_email_address@domain.invalid:

What should I do to accommodate this in Capistrano? When I use
Capistrano to deploy, the correct database.yml isn’t put into place
where it should be. I’m not sure where to begin to fix this situation.

Read up on “Extending Tasks”:
http://manuals.rubyonrails.com/read/chapter/102#page277

Basically, you should create an “after_update_code” task which will
link, copy or whatever you need to put the right database.yml file in
it’s proper place.

Hope that helps !


#4

Ray B. wrote:

But, why don’t you just put all of your database configurations info
into database.yml and select the one that you want to use based on
whether you are in development, testing or production. This is the
standard way to do this in Rails. Just have a look at the database.yml
produced by “rails .”

Yeah, but that would make sense :slight_smile:

That’s actually what I should do, but at the moment my production server
seems to think it’s running in “development” and I’m not sure how to set
it. I just posted the question on the server’s support forums, but til
now I’ve just been ignoring it and making do.

Jeff


#5

Jeff C.man wrote:

That’s actually what I should do, but at the moment my production server
seems to think it’s running in “development” and I’m not sure how to set
it. I just posted the question on the server’s support forums, but til
now I’ve just been ignoring it and making do.

If all else fails, have a look at the top of config/environment.rb.
There is a method there that will set you server into production mode by
default.

Then you just have to set RAILS_ENV to development on your local box.

Ray


#6

I’ve found that setting RAILS_ENV in /etc/bash_profile (or equivalent)
generally will do the trick.


– Tom M.


#7

Tom M. wrote:

I’ve found that setting RAILS_ENV in /etc/bash_profile (or equivalent)
generally will do the trick.


– Tom M.

I’m a Linux noob, what would be the exact syntax?

set RAILS_ENV=production

? Or should it be

set RAILS_ENV=“production”

Or something different?

Jeff


#8

export RAILS_ENV=production


– Tom M.


#9

Just to add on this - you need the rails runner user to have this
setting in it’s ~/.bash_profile. If it’s cgi, then it’s the web server
user, if it’s FastCGI launched through spawner, it’s the user calling
spawner.

Guy.

On 3/29/06, Tom M. removed_email_address@domain.invalid wrote:

But, why don’t you just put all of your database configurations info
seems to think it’s running in “development” and I’m not sure how
Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Family management on rails: http://www.famundo.com - coming soon!
My development related blog: http://devblog.famundo.com


#10

I got a reply from RailsPlayground, my web host, and they advised me to
set the environment to “production” by uncommenting the relevant line in
my application’s “environment.rb”, which… doesn’t exactly help me.

If I set production in the environment.rb, I’m still in the situation
where Capistrano and SVN would be deploying my local environment.rb to
the live server, which would just end up with me running production at
home and on live, rather than development in both places, like I am now.

Not sure what to do about it.

Jeff


#11

Jeff C.man wrote:

I got a reply from RailsPlayground, my web host, and they advised me to
set the environment to “production” by uncommenting the relevant line in
my application’s “environment.rb”, which… doesn’t exactly help me.

If I set production in the environment.rb, I’m still in the situation
where Capistrano and SVN would be deploying my local environment.rb to
the live server, which would just end up with me running production at
home and on live, rather than development in both places, like I am now.

Not sure what to do about it.

Try this from my earlier response:

Then you just have to set RAILS_ENV to development on your local box.

You have more control over your local environment than you have over
your server environment if you are in a hosted environment.

Ray


#12

Alternately, create a ‘shared’ directory at the same level as ‘current’.
In ‘shared/config’ place the ‘database.yml’ file of interest, then
symlink (ln -s) to it in an after_update in your deploy.rb.

I do similar things to wire up ‘vendor’ and the like.

-San