On handling staging servers - Ruby on Rails: Core

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion On handling staging servers
Received-SPF: pass (google.com: domain of hasmanyj...@gmail.com designates 209.85.160.53 as permitted sender) client-ip=209.85.160.53;
Date: Fri, 13 Apr 2012 13:43:02 -0700
From: Josh Susser <j...@hasmanythrough.com>
To: rubyonrails-core@googlegroups.com
Message-ID: <0FAABEBDF6BD44438066F541308072C4@gmail.com>
In-Reply-To: <4F888DEA.6080902@gmail.com>
References: <4F8885E2.1040700@gmail.com>
 <9A74E54159FA4D46B1CA3D9AFECE62B4@gmail.com> <4F888DEA.6080902@gmail.com>
Subject: Re: [Rails-core] On handling staging servers
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f888fd6_2b8fa025_39c"

--4f888fd6_2b8fa025_39c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Friday, April 13, 2012 at 1:34 PM, Rodrigo Rosenfeld Rosas wrote:
> Em 13-04-2012 17:30, Josh Susser escreveu:
> > The best way to set up a staging server is for it to be configured as 
> > close to production as possible, so I always run my staging server 
> > using the production.rb environment. If there are differences (like 
> > which S3 bucket to use), I put them in ENV settings or in files that 
> > aren't under version control.
> > 
> 
> 
> That way you'd need an extra backup (aside from your git repository) for 
> storing each environment data, unless you're using something like 
> Capistrano or Chef. But setting up such environments when you're 
> starting your application may seem like overkill.
> 
> 


Storing server configuration in your app's git repo is not ideal. Chef recipes are much better. And if you're at the point where you need a staging server, you're definitely at the point where you should be using automation for managing your servers. How else will you know that your staging server accurately reflects the production configuration? You can go a long time without a staging server - often much longer than you can without configuration automation.

And yes, you should store those recipes in version control. Just not in the app's repo. There are tons of reasons for keeping those things separate (security, decoupling, etc.)



--4f888fd6_2b8fa025_39c
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><span style=3D=22color: rgb(160, 160, 168); =22>On =46=
riday, April 13, 2012 at 1:34 PM, Rodrigo Rosenfeld Rosas wrote:</span></=
div>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div>Em 13-04-2012 17:30, Josh Susser=
 escreveu:</div><blockquote type=3D=22cite=22><div><div>The best way to s=
et up a staging server is for it to be configured as </div><div>close to =
production as possible, so I always run my staging server </div><div>usin=
g the production.rb environment. If there are differences (like </div><di=
v>which S3 bucket to use), I put them in ENV settings or in files that </=
div><div>aren't under version control.</div></div></blockquote><div><br><=
/div><div>That way you'd need an extra backup (aside from your git reposi=
tory) for </div><div>storing each environment data, unless you're using s=
omething like </div><div>Capistrano or Chef. But setting up such environm=
ents when you're </div><div>starting your application may seem like overk=
ill.</div></div></div></span></blockquote><div><br></div><div>Storing ser=
ver configuration in your app's git repo is not ideal. Chef recipes are m=
uch better. And if you're at the point where you need a staging server, y=
ou're definitely at the point where you should be using automation for ma=
naging your servers. How else will you know that your staging server accu=
rately reflects the production configuration=3F You can go a long time wi=
thout a staging server - often much longer than you can without configura=
tion automation.</div><div><br></div><div>And yes, you should store those=
 recipes in version control. Just not in the app's repo. There are tons o=
f reasons for keeping those things separate (security, decoupling, etc.)<=
/div><div><br></div><div><br>
                </div>
            
--4f888fd6_2b8fa025_39c--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
