Running an out-of-the-box stack like MAMP may be fine for part-time tinkerers, but if you’re writing code for a serious site you’ll quickly realise that it’s important to develop against the same version of the stack that’s running in the production environment. You’d be amazed at how many subtle bugs emerge between two minor point releases of PHP, APC, MySQL or any other of the myriad components. Catching them early is crucial, and the easiest way to do that is to use a virtualised developer environment. A good choice for Apple OSX is VMWare Fusion:

VMWare Fusion 3 is pretty slick. You have a checkout of the code on your Mac, then you use the shared folders in VMWare to make the code available in the Centos VM, and point the Apache webroot at it. That makes it painless to edit code in your text editor or IDE of choice and have the changes immediately picked up by the webserver.

A full blown local stack also has the advantage of turning every developer and themer into an amateur sysadmin, and giving everyone true insight into how the production environment holds together. I’ve personally been pleasantly surprised at how easy Red Hat is to pick up, having always been a Debian/Ubuntu fan in the past.

In addition to Apache httpd and PHP 5.3, the Centos VM runs Varnish reverse proxy and Memcached. For MySQL, we have a dedicated beefy server in the office on the local subnet that everyone shares, and every developer has their own database copy on the server. Running MySQL in a virtual machine is not a good idea for us, as the Economist database is enormous and imports take too long. The version of MySQL is the same as in production, we bought a single enterprise license to ensure it’s absolutely representative of the live environment.

A complete copy of the production database is currently 1.8 GB compressed. Every night, a script runs in production that sanitises all sensitive user information in a copy of the data, then mysqldumps it to Amazon’s S3 storage. There’s a cron job that runs on the office database server every night, dropping and re-importing all the developer databases using the fresh dump from live.

Thus, every morning when we get to work, we know that we have the most current data and configuration to work with. It also means all database changes have to be made in code, using exportables (Features, Views) and update hook functions, which is exactly what we want - configuration flows out in code, content flows backwards in the data.

Those of us that work from home occasionally, but have iMacs as our primary machines as opposed to laptops, have devised a method of working seamlessly from home. We connect to The Economist network using the corporate VPN, at which point we can access both the virtual machine and the Mac - as the VM runs in bridged mode and has it’s own IP on the network. This makes working from anywhere extremely easy as long as your desktop stays up.