> role :web, "lamp1, lamp2" #Cluster Production > role :web, "lamp3", #Server Dev
> Its possible to deploy my application on lamp3 only or lamp1 and lamp2 > only ?
You might try this in your recipe file:
case ENV["TARGET"] when "prod" role :web, "lamp1, lamp2" #Cluster Production when "dev" role :web, "lamp3", #Server Dev end
Then run:
TARGET=prod cap deploy
in order to deploy to the production machines, or:
TARGET=dev cap deploy
in order to deploy to the dev machine.
Many people have this kind of situation (usually with 3 environments: dev, staging and production). Just search the capistrano and rails groups for "staging" and you'll find all the talks about it... I have a feeling the Jamis is planning some solution for it in the next big release. ;-)
> Many people have this kind of situation (usually with 3 environments: > dev, staging and production). Just search the capistrano and rails > groups for "staging" and you'll find all the talks about it... I have > a feeling the Jamis is planning some solution for it in the next big > release. ;-)
I'm curious why you have that feeling. :) Even more, though, I'm curious what you think Capistrano ought to do about this. Personally, I think the case statement is a great solution. Totally fine. What could Capistrano do that would be cleaner and easier to read than:
case ENV['STAGE'] when "production" role .... set ... ... when "development" .... ... end
If it is the environment variable that looks klunky you, you can use capistrano variables instead:
>> Many people have this kind of situation (usually with 3 environments: >> dev, staging and production). Just search the capistrano and rails >> groups for "staging" and you'll find all the talks about it... I have >> a feeling the Jamis is planning some solution for it in the next big >> release. ;-)
> I'm curious why you have that feeling. :) Even more, though, I'm > curious what you think Capistrano ought to do about this. Personally, > I think the case statement is a great solution. Totally fine. What > could Capistrano do that would be cleaner and easier to read than:
> case ENV['STAGE'] > when "production" > role .... > set ... > ... > when "development" > .... > ... > end
> If it is the environment variable that looks klunky you, you can use > capistrano variables instead:
> I have found that the cleanest way to do staging and production > tasks like this is this way:
> task :production do > role :web, '65.74.169.199:8192' > role :app, '65.74.169.199:8192' > role :db, '65.74.169.199:8192', :primary => true > end
> task :staging do > role :web, '65.74.169.199:8194' > role :app, '65.74.169.199:8194' > role :db, '65.74.169.199:8194', :primary => true > end
> Then you can do:
> $ cap staging deploy > $ cap production deploy
> Cheers- > -Ezra
> On Mar 29, 2007, at 7:49 AM, Jamis Buck wrote:
>> On Mar 28, 2007, at 2:02 AM, dubek wrote:
>>> Many people have this kind of situation (usually with 3 >>> environments: >>> dev, staging and production). Just search the capistrano and rails >>> groups for "staging" and you'll find all the talks about it... I >>> have >>> a feeling the Jamis is planning some solution for it in the next big >>> release. ;-)
>> I'm curious why you have that feeling. :) Even more, though, I'm >> curious what you think Capistrano ought to do about this. Personally, >> I think the case statement is a great solution. Totally fine. What >> could Capistrano do that would be cleaner and easier to read than:
>> case ENV['STAGE'] >> when "production" >> role .... >> set ... >> ... >> when "development" >> .... >> ... >> end
>> If it is the environment variable that looks klunky you, you can use >> capistrano variables instead:
Yes, a staging config should be standard in Rails and Capistrano imho. For safety and laziness, I usually set the defaults to staging at the top of deploy.rb:
set :rails_env, :staging set :deploy_to, "/my/app/path/staging"
desc "Production setup" task :production do set :rails_env, :production # override :staging default set :deploy_to, "/my/app/path/production" end
Then I play with staging via "cap deploy", "cap migrate" and friends. When all is fine on the staging host, it's time to
cap production deploy_with_migrations
and pray that no migration breaks the precious production db ;-)
Tip of the day: use a dump of your production db as a sample to test your software and migration procedures on the staging host.
Just my 2 cents,
JFG
On 29 Mar, 19:54, Ezra Zygmuntowicz <ezmob...@gmail.com> wrote:
> I have found that the cleanest way to do staging and production > tasks like this is this way:
> task :production do > role :web, '65.74.169.199:8192' > role :app, '65.74.169.199:8192' > role :db, '65.74.169.199:8192', :primary => true > end
> task :staging do > role :web, '65.74.169.199:8194' > role :app, '65.74.169.199:8194' > role :db, '65.74.169.199:8194', :primary => true > end
> Then you can do:
> $ cap staging deploy > $ cap production deploy
> Cheers- > -Ezra
> On Mar 29, 2007, at 7:49 AM, Jamis Buck wrote:
> > On Mar 28, 2007, at 2:02 AM, dubek wrote:
> >> Many people have this kind of situation (usually with 3 environments: > >> dev, staging and production). Just search the capistrano and rails > >> groups for "staging" and you'll find all the talks about it... I have > >> a feeling the Jamis is planning some solution for it in the next big > >> release. ;-)
> > I'm curious why you have that feeling. :) Even more, though, I'm > > curious what you think Capistrano ought to do about this. Personally, > > I think the case statement is a great solution. Totally fine. What > > could Capistrano do that would be cleaner and easier to read than:
> > case ENV['STAGE'] > > when "production" > > role .... > > set ... > > ... > > when "development" > > .... > > ... > > end
> > If it is the environment variable that looks klunky you, you can use > > capistrano variables instead:
> Yes, a staging config should be standard in Rails and Capistrano imho. > For safety and laziness, I usually set the defaults to staging at the > top of deploy.rb:
> set :rails_env, :staging > set :deploy_to, "/my/app/path/staging"
> desc "Production setup" > task :production do > set :rails_env, :production # override :staging default > set :deploy_to, "/my/app/path/production" > end
> Then I play with staging via "cap deploy", "cap migrate" and friends. > When all is fine on the staging host, it's time to
> cap production deploy_with_migrations
> and pray that no migration breaks the precious production db ;-)
> Tip of the day: use a dump of your production db as a sample to test > your software and migration procedures on the staging host.
> Just my 2 cents,
> JFG
> On 29 Mar, 19:54, Ezra Zygmuntowicz <ezmob...@gmail.com> wrote:
> > I have found that the cleanest way to do staging and production > > tasks like this is this way:
> > task :production do > > role :web, '65.74.169.199:8192' > > role :app, '65.74.169.199:8192' > > role :db, '65.74.169.199:8192', :primary => true > > end
> > task :staging do > > role :web, '65.74.169.199:8194' > > role :app, '65.74.169.199:8194' > > role :db, '65.74.169.199:8194', :primary => true > > end
> > Then you can do:
> > $ cap staging deploy > > $ cap production deploy
> > Cheers- > > -Ezra
> > On Mar 29, 2007, at 7:49 AM, Jamis Buck wrote:
> > > On Mar 28, 2007, at 2:02 AM, dubek wrote:
> > >> Many people have this kind of situation (usually with 3 environments: > > >> dev, staging and production). Just search the capistrano and rails > > >> groups for "staging" and you'll find all the talks about it... I have > > >> a feeling the Jamis is planning some solution for it in the next big > > >> release. ;-)
> > > I'm curious why you have that feeling. :) Even more, though, I'm > > > curious what you think Capistrano ought to do about this. Personally, > > > I think the case statement is a great solution. Totally fine. What > > > could Capistrano do that would be cleaner and easier to read than:
> > > case ENV['STAGE'] > > > when "production" > > > role .... > > > set ... > > > ... > > > when "development" > > > .... > > > ... > > > end
> > > If it is the environment variable that looks klunky you, you can use > > > capistrano variables instead:
