Tuesday, June 2, 2009

Dev, Staging, and Production

There's a pretty good chance you know this, but I want to make sure that the other goons in the world have a plethora of results when they query "why should I have separate environments?"

If you are responsible for any kind of development group, there's some things that they need in order to do their job, while at the same time protecting them from themselves. One of those things is their own environment (development), distinct from the environment which everyone else is using (production). It isn't completely necessary, but incredibly useful, for there to be an intermediate environment (staging).

The production environment is the Ivory Tower, where only the Blessed Code may enter (to be cursed by the users). There may be some diagnostics utilities installed, but they should rarely be invoked. Generally, if you're having to think too hard about production, you've already done something wrong.

The development environment is the Wild West. You want your developers to go a little crazy and experiment. That's how they come up with really cool ideas, and where they find out that most of those ideas are entirely unworkable.

Staging is the Suburbs. It's pretty nice there, the streets are clean, the lawns are mowed. Things are very predictable, but not particularly uptight.

Yes, but why do we need all three?

They are serving three different purposes.

Production is what your users/customers see. They shouldn't be bothered by anything. If there's a change, it should be seamless and make things better. It should be fast and stable. Troubleshooting, testing, developing - all of these things interfere with that experience.

Staging is "production for developers". It, too, should be very predictable. It doesn't actually serve any purpose to the end user so mistakes are acceptable. Not desirable, but acceptable. Developers have the opportunity to troubleshoot and test, mostly to their heart's content. The whole point is to give developers a place to do these things without impacting production, therefore it should always be as close a duplicate to production as possible.

Development is for developers. Broken links, bad data, ugly pages: all of these are just hunky-dory here. It should have a lot of the characteristics of production - the
closer it matches, the easier it will be to deploy to staging. At the same time, it isn't unusual to tear it up.

They each have to be managed differently, but I'll save that for another post.

No comments:

Post a Comment