I totally agree with what Josh said. When I used staging rails environment in the past it always ended up with some weird tweaks that I had to do. If you're running staging server on production environment all you need to do is to remember to keep configuration outside the code as Josh mentioned, which is a good idea anyway.
On Friday, April 13, 2012 10:30:14 PM UTC+2, Josh Susser wrote: > > 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. So I think having a staging.rb file is the wrong way to go. > > I also always have a demo environment that is meant for feature > acceptance, which is a different role than staging and often has different > configuration. I think this is very common for projects that use agile > where the PM does story acceptance. But I don't expect that to become > standard in Rails. I think development, testing, and production are really > the only ubiquitous environments I've seen, and are exactly the right set > for Rails to include as standard. > > -- > Josh Susser > http://blog.hasmanythrough.com > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/neaoxMLA7CYJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
