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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
