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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
