| 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. |