Forum: Ruby on Rails Capistrano/SVN: Deploying different database.yml for live?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-03-30 04:15
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
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-03-30 04:26
(Received via mailing list)
Jeff Coleman 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
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 François Beausoleil (fbeausoleil)
on 2006-03-30 04:32
(Received via mailing list)
Hello Jeff !

2006/3/29, Jeff Coleman <progressions@gmail.com>:
> 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 !
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-03-30 04:43
Ray Baxter 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 :)

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
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-03-30 05:00
(Received via mailing list)
Jeff Coleman 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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-30 05:00
(Received via mailing list)
I've found that setting RAILS_ENV in /etc/bash_profile (or equivalent)
generally will do the trick.

--
-- Tom Mornini
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-03-30 05:25
Tom Mornini wrote:
> I've found that setting RAILS_ENV in /etc/bash_profile (or equivalent)
> generally will do the trick.
>
> --
> -- Tom Mornini

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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-30 06:27
(Received via mailing list)
export RAILS_ENV=production

--
-- Tom Mornini
Cbff7ea94c9b2c4d5f7cfefd25be9ae2?d=identicon&s=25 Just Someone (Guest)
on 2006-03-30 07:04
(Received via mailing list)
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 Mornini <tmornini@infomania.com> 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
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> 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
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-03-30 07:33
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
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-03-30 08:19
(Received via mailing list)
Jeff Coleman 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
4b9ebad5fe52ce89dc12aaf34502d518?d=identicon&s=25 San (Guest)
on 2006-03-30 12:08
(Received via mailing list)
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 topic is locked and can not be replied to.