# Production vs. staging servers

**URL:** <https://www.ruby-forum.com/t/production-vs-staging-servers/107562>\
**Category:** Deployment\
**Created:** [June 23, 2007, 8:03am UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562 "2007-06-23T08:03:20Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Faisal\_N\_Jawdat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/34f0e0/32.png) [@Faisal\_N\_Jawdat](https://www.ruby-forum.com/u/Faisal_N_Jawdat)\
**Post date:** [June 23, 2007, 8:03am UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562/1 "2007-06-23T08:03:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Faisal\_N\_Jawdat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/34f0e0/32.png) [@Faisal\_N\_Jawdat](https://www.ruby-forum.com/u/Faisal_N_Jawdat)\
**Post date:** [June 23, 2007, 11:12am UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562/2 "2007-06-23T11:12:32Z")

</div>

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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> done it?
> 
> -faisal
> 
> >

## –

Andrew S. \* [http://semprebon.blogspot.com/](http://semprebon.blogspot.com/)

---

<div class="post-metadata">

**Author:** ![Faisal\_N\_Jawdat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/34f0e0/32.png) [@Faisal\_N\_Jawdat](https://www.ruby-forum.com/u/Faisal_N_Jawdat)\
**Post date:** [June 23, 2007, 11:35pm UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562/3 "2007-06-23T23:35:54Z")

</div>

On 6/23/07, Faisal N Jawdat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![Faisal\_N\_Jawdat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/34f0e0/32.png) [@Faisal\_N\_Jawdat](https://www.ruby-forum.com/u/Faisal_N_Jawdat)\
**Post date:** [June 26, 2007, 11:12am UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562/4 "2007-06-26T11:12:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Faisal\_N\_Jawdat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/34f0e0/32.png) [@Faisal\_N\_Jawdat](https://www.ruby-forum.com/u/Faisal_N_Jawdat)\
**Post date:** [June 23, 2007, 10:14pm UTC](https://www.ruby-forum.com/t/production-vs-staging-servers/107562/5 "2007-06-23T22:14:45Z")

</div>

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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

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

–  
Chris B.  
removed\_email\_address@domain.invalid