Building the Ultimate Staging Server

During our big rebuild at Concur I got to research and build out the ultimate staging server for our big re-design.  

Like most companies concur's internal network is locked to the outside world.  This little challenge makes it hard to co-develop with outside developers and give outside vendors access to your staging site.   We decided to use a cloud provider to host the staging server which made it possible for all of us to work together.  The site was set up on a ubuntu install at Linode.  Linode is a super cool host but I would not use them again.  They just had too much down time during the project.  Since then I have switched to the RackSpace cloud and love it!

Once I built up the base server it was time to hook up Subversion (SVN) and a post commit hook to the staging environment's website.  Woh that sounds techie...  In layman's terms this allows a developer to check in a file to the file repository then system updates the staging website instantly.  We took this approach so that our developers could work locally and receive the latest files by running a update.  WHen their code was complete they would then check in.

Our folder structure had three top folders for this project:

• Assets, contained psd files for the theme.
• Build, contained db backups and drupal's files folder zipped to match each db backup.
• Core_Files, contained the drupal folder.

Each night we backed up the database and checked it in to SVN so the devs could refresh each morning.  We also would zip up Drupal's files directory and checked that in to our build folder with a file name that corresponded to the db backup.

Development is really only have the work with Drupal.  A lot of the work is done on the content side.  For this we had our content team and in house dev guys slamming the site with the content updates and imports.  Totally amazing how a site can go from one page (node/1) to a thousand nodes within a few weeks.

Things we learned:  

• Use Rackspace :-)
• Check peoples work before check in's
• Isolate your  CSS with a pre-class and contain it within comments.
• Create naming conventions for blocks and contexts ahead of time.