Ruby Forum Rails deployment > production vs. staging servers

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

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 <faisal@faisal.com> wrote:
> done it?
>
> -faisal
>
>
> >
>


--
--
Andrew Semprebon * http://semprebon.blogspot.com/

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 Semprebon <semprebon@gmail.com> wrote:
> > From an operational point of view I want a production server and a
> > > >
> >
>


--
Chris Bailey
chris.bailey@gmail.com

On 6/23/07, Faisal N Jawdat <faisal@faisal.com> 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

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.