Rails - Mar 2006 - Capistrano/SVN: Deploying different database.yml for live?

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


-- 
Posted via http://www.ruby-forum.com/.

Jeff Coleman wrote:
> 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.
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

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 !
--
Fran?ois Beausoleil
http://blog.teksol.info/

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

-- 
Posted via http://www.ruby-forum.com/.

Jeff Coleman wrote:
> 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.

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

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

--  
-- Tom Mornini

On Mar 29, 2006, at 6:43 PM, Jeff Coleman wrote:
> 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
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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

-- 
Posted via http://www.ruby-forum.com/.

export RAILS_ENV=production

--  
-- Tom Mornini


On Mar 29, 2006, at 7:25 PM, Jeff Coleman wrote:
> 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
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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:
> I''ve found that setting RAILS_ENV in /etc/bash_profile (or
equivalent)
> generally will do the trick.
>
> --
> -- Tom Mornini
>
> On Mar 29, 2006, at 6:43 PM, Jeff Coleman wrote:
>
> > 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
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> > 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

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

-- 
Posted via http://www.ruby-forum.com/.

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

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



Francois Beausoleil wrote:
> 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 !
> --
> Fran?ois Beausoleil
> http://blog.teksol.info/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails