[ollysb]

This is one of the areas where heroku does a great job. It's very good at cloning apps, if you're using their addons(memcache, redis, etc.) it'll take care of provisioning new instances automatically. We use amazon rds but that's the only thing we have to setup if we want a new environment. Now that postgres is available on amazon we'll probably switch to that which will mean we can even use a cheapo heroku postgres instance for product demos etc.

With regards to setting up a company to do this, I'm not sure. A staging environment really needs to be as close as possible to production. Perhaps docker will become enough of a standard that it'll be easy to match production apps much easier in different clouds...

[ubermuda]

When I tell people about an automated staging deployment platform (let's not talk about a company yet, even if that is indeed the ultimate goal), they often ask "what does your product do that heroku doesn't?". That answer is simple, it's in the vision of the product. Heroku is production platform, and everything is geared toward great performance, ease of setup and scalability. IMHO, only one of these characteristics is essential to a staging platform: ease of setup.

I think the real added value of a successful staging platform will come from staging specific features, like making everything automated, easing feedback gathering, one-click staging/prod mirroring, etc. Docker and other isolation or virtualization technologies are most certainly a step in the good direction, but that's precisely what I'm trying to mesure with that survey and the discussion around it.

[grey-area]

By far the biggest problem with this concept is that the staging environment must exactly mirror the production environment, as the parent pointed out.

So it's going to come down to being able to reproduce the production in staging (db, web server, plugins, bandwidth, memory, storage, data and the exact version of all of these - every bit of state which might affect production), which would be an awful lot easier if you are also serving the production side, or perhaps if you have a very limited set of supported production targets. It's a tricky problem and one that's hard to solve if you don't control production.

Having set up a few staging environments, here are things Id find handy/essential, for what it's worth:

Exact duplication of production setup

Easily getting scrubbed production data into staging

Easy replication (probably with version control)

Easy deployment to production

Easy rollback (probably with multiple instances)

Feedback might be nice I guess if you had a sort of comment on this page system, could easily grow out of control though into a ticket management nightmare - many managers use email/phone for this and are hard to wean off it.

NB that if you don't have no.1 on that list, nothing else matters, and people are not going to want to use a different tool to deploy dev and production.