At GORGES we prefer to set up a staging server or website for our bigger projects. I would even call it a requirement since it can be used by the customer and our quality assurance staff to review both progress and the release candidate before publishing a website to a production site.
Usually developers work directly on their workstations or laptops, and a development environment has both web and database services running similar to a production server. Ideally a development environment should have the same versions of services as the production server, for example PHP 5.2 or Ruby 1.9. On more than one occasion I have been bitten by writing MySQL 4.3 or 5 code, but the production server has an older version of MySQL without sub-query support so the queries had to be rewritten.
Usually these development services are customized for development, for example the database does not have to be hardware-optimized and the web service can have debugging tools enabled. I prefer to turn on all warning messages, so any identified problems that are not severe enough to halt page serving will be shown either in a log file or onscreen.
Just as important with having a staging server is to have clean and well-structured publishing scripts. If you are relying on a manual process to upload files using FTP, then it is possible to skip an updated file by mistake. Publishing scripts come in all sorts of flavors and approaches – we have both “pull” methods that use server-side scripts, and “push” scripts that execute on the developer’s computer and automatically upload files to the server. The push scripts are built on Capistrano, which although it is based on ruby we sometimes use at Gorges for non-ruby websites.
We routinely protect our staging servers from prying eyes and search engines by using HTAuth username and passwords. Once a website is scanned by a Google, Bing, or other web crawler then it is out of your control.
Having a staging server doesn’t mean much unless it is actually used to test new features and look for bugs. Quality assurance is important, and I have yet to meet a developer that produces bug-free code or see a unit testing system that covers 100% of a web application feature set.
Not covered in this post is the issue of database migrations between developer environment and a staging server, and also from a staging server to a production machine. These can be tricky, but as with all challenges the proper planning will guide you to the best solution.
After the application or update goes live to the production server most staging servers are continued as “sand boxes” to support additional updates and testing.