I know, everyone's Capistrano deployment is unique, however, mine may be like one I have never seen before.
1. The app is contained on 1 server. I do not have multiple servers.
2. The app is actually deployed twice into two different directories.
Now, #2 is causing me my problems. I can handle the database.yml, environment.rb, etc... just fine. The reason I need to deploy the application into two different locations is one application is our production server, the other application is a training environment. Obviously they have different database backends.
Anyone have an idea on how to accomplish this task?
Jeremy
Just saw something cool on jamis’ blog, for handling this, credit goes to Ben Bleything:
-
**[Ben Bleything](http://blog.bleything.net/)** said about 3 hours later:
Another
(and IMHO, better) option for staging is to simply create new tasks
that changes whatever you need to change and then calls the deploy
action:
task :stage, :roles => [:app, :db, :web] do
set :deploy_to, "/var/www/staging"
deploy
end
It’s not as flexible as the env var method, but it’s hard to argue with cap stage
See:
http://jamis.jamisbuck.org/articles/2006/08/30/the-future-of-capistrano#comments
So, I imagine you could have a normal deploy task but named something different,
do your normal deploy stuff
and then set the new :deploy_to dir, and call deploy again.
cheers! good luck
I have a similar situation where I have a staging environment and a
production environment on the same server in different directories. The
way I got around it was to write a couple of wrapper tasks that change
deploy_to and then call the deployment task:
task :stage, :roles => [:app, :db, :web] do
set :deploy_to, "/var/www/staging"
deploy
end
Of course, you could do both at the same time:
task :mydeploy, :roles => [:app, :db, :web] do
set :deploy_to, "/var/www/staging"
deploy
set :deploy_to, "/var/www/production"
deploy
end
Hope that helps!
Ben
Another option just occurred to me, that (if possible) is probably a
much cleaner solution.
Set up another environment in your app... add a new section to your
database.yml, copy your production.rb in config/environments, etc for
your training environment.
Then, set up your webserver to fire up two instances of the same
codebase, one in the training environment and one in production.
I can't think of any reason why this wouldn't work, but I also haven't
tried it, so grain of salt and all that.
Ben
desc “Set training environment”
task : training do
role :app, “app server” # possibly the same as production
role :web, “web server” # ditto
set :rails_env, :training
set :deploy_to, “/opt/rails/#{application}/training”
end
desc “Set production environment”
task :production do
role :app, “app1.whatever.com”, “app1.whatever.com”
role :web, “web1.whatever.com”, web2.whatever.com
set :rails_env, :production
set :deploy_to, “/opt/rails/#{application}/production”
end
Now:
$ cap production deploy
$ cap training deploy
$ cap <production/training>
Etc.
Isn't that what I said in my first email?
I was trying to come up with a way to not require one's code to be in
two places at once.
Ben
Ahh, I see the difference now. I didn't know you could chain tasks like
that. Very nice!
Ben