February 03, 2011
Nothing helps you sleep better at night like a staging environment that’s faithful to your production setup. That means your staging environment has the same Linux distro, same version of Ruby and gems, the same Apache and Passenger configuration, etc.
We’ve found that an inexpensive “always-on” VPS instance is better as a staging environment than a cloud instance we have to spin up and down. Why? Spinning up a cloud instance takes time. We’re more likely to actually use our staging environment if it’s as low-friction as possible to do so.
A staging environment isn’t free—you’ll spend money on the VPS, and you’ll spend time configuring and maintaining it. However, the peace of mind you’ll get is a great return on investment.
If setting up your staging environment is difficult, you have something to work on: a repeatable process for configuring production-like boxes. Remember, your staging environment should mimic your production environment as closely as possible. If you have a scripted process for setting up production boxes, then setting up your staging environment will be trivial.
If you’re like many organizations, however, there is no authoritative definition for production. Instead, it has evolved over time with manual tweaks and optimizations. In that case, the staging environment is a perfect opportunity to pull together a repeatable script. It doesn’t have to be automated (ours is not)—but it does need to be written down.
We Rubyists are lucky—there are tools for just about everything. We use capistrano multistage for staging deployments. It’s straightforward to set up, and makes staging deployments completely frictionless.
You should end up with a “staging” file In your
config/deploy directory, but not in your
config/environments directory. You’ll use the your production environment for staging.
The harder part is simulating production-like traffic on your staging server. In a perfect world, you would have holodeck for deployments. We don’t have a solution for this yet—ideas are welcome!
This is Part 4 in our Developer Happiness series. See previous articles: