[carbon8]

Short-lived staging environments (eg, a temporary clone of a production environment) certainly have a place, such as when making architectural changes, but these kinds of changes are generally not happening on a regular basis if you are making incremental changes and doing continuous deployment.

I'm sure that there are companies that have a valid engineering need for perpetual staging environments rather than feature flags, but I've seen absolutely no evidence that staging servers are commonly engineering driven. Certainly in every part of the web startup world I've had contact with or heard about, staging environments have consistently been for product QA in organizations with heavy-handed processes and/or product management by non-technical stakeholders.

Edit for the people responding: This is not about haphazardly pushing to production. You should familiarize yourselves with continuous integration (http://en.wikipedia.org/wiki/Continuous_integration) and the various deployment strategies of major web companies.

[autarch]

I'm a dev at a company and I pushed for us to have a staging environment _and_ QA. When I started at my current job, it was common practice to edit code in production, and there was no testing (automated, QA, anything).

In our case, having a staging server (which is really a prod server since it's used for some internal stuff) gives us a chance to check a few things:

1. The installer still installs everything properly. 2. The main website works 3. Web services work

We don't have any hard and fast rules about how long things sit on staging, but having a staging system is useful.

So there you have it, a staging environment driven by engineering.

[silverbax88]

Staging servers are not only a great idea, they are a life saver (read: job saver/career saver) when you are running large, mission critical apps.

I push things right into production when I'm playing with a new site. I use a staging server when I'm working on something serious.

[diek]

You honestly can't think of good engineering reasons not to push new code directly into production?

[angersock]

too busy crushing it to use a staging server

sorry you aren't a technical coder

you probably even file bugs instead of just monkey-patching it in production like a real man

(srcub)

[edabobojr]

You might want to do fewer, less frequent releases in order to provide training to end users. You might also want to do do fewer, less frequent releases in order to facilitate a marketing push centered around the release.