Production vs. staging servers

Rails Deployment
1

In Rails I have the development/test/production split, but…

From an operational point of view I want a production server and a
staging server, with the staging server mirroring the setup of the
production server as much as possible so I can shake out issues that
are environment-specific.

Any thoughts on how to do this or pointers to those who’ve already
done it?

-faisal

2

Make a copy the production.rb in config/environments/ and call it
staging.rb,
and add a new section to your database.yml called staging. This will
give
you a new environment called staging, which you then can modify as
needed.

On 6/23/07, Faisal N Jawdat [email protected] wrote:

done it?

-faisal

–

Andrew S. * http://semprebon.blogspot.com/

3

On 6/23/07, Faisal N Jawdat [email protected] wrote:

From an operational point of view I want a production server and a
staging server, with the staging server mirroring the setup of the
production server as much as possible so I can shake out issues that
are environment-specific.

Adding a file to config/environments/ is an obvious first step.

Then you have to do something about managing versions of things
external to your app: libraries, Ruby interpreter and so on. Whenever
you upgrade one of these, you want to first upgrade it in the test
environment, then propagate to production.

Vendor everything that can be, including Rails (i.e., place in
[yourapp]/vendor and commit to version control).

It’s also possible to set up a private gem and/or RPM repository for
packages that cannot be vendored. Install those packages in the test
environment first, then if it works OK, upload the package to the
repository. Then have all your production boxes updated from the
repository. This will obviously cost some time and effort to set up
and maintain. You need to decide if it makes sense in your context. It
probably is worth doing if you have multiple production servers and
high uptime requirements.

–
Alex Verkhovsky

4

We have a production and staging setup as well (Under LiteSpeed 3)
just as Andrew and Chris outline. Commands like “cap staging deploy”
or “cap production rollback” work just fine.

5

Also, if you are using Capistrano to deploy, you can create targets
that setup the role definitions, so that you can also do deploys to
your staging environment. We have a half dozen different deploy
targets, and deploy by specifying the target, and
deploy/deploy_with_migrations, e.g.: “cap staging deploy”

One of the cap deployment target tasks simply looks like:

desc “Target the empqa cluster for remote operations”
task :empqa do
set :deploy_target, ‘empqa’
set :db_server, ‘empqa-07’
role :web, ‘empqa-02’, ‘empqa-04’
role :app, ‘empqa-02’, ‘empqa-04’
role :db, “#{db_server}”, :primary => true
end

(Note that the “db_server” variable we set is so that we can generate
the proper database.yml.)

On 6/23/07, Andrew S. [email protected] wrote:

From an operational point of view I want a production server and a

–
Chris B.
[email protected]