in Development, DevOps, Rails

Beware of the staging environment

When pushing changes to your website you want to test them in an environment similar to your production one – without the fear of breaking something for your customers: voilà, staging.

Staging should mirror production in most aspects, but some things just have to be different e.g. crash-reporting, limiting access

A project of mine is using rails, which has excellent support for different environments and even comes with three predefined ones: development, test and production. They recommend creating a new env for staging, which sounds sane. You have to copy your production config, adapt your Gemfile, find every usage of the production env and …,

Wait, that doesn’t sound sane!

And it isn’t. You don’t want to duplicate code or converge too much from your production env. This blogpost from heroku explains it better.

tl;dr: Use production environment for staging, express differences with environment variables