WordPress Deployment Options

Ok I’ve had enough – I NEED better options for deploying WordPress websites.

Right now I manage a LOT of WordPress websites – probably close to 40 sites – maybe more. In fact I’ve lost count!

Right now my development process goes something like this.

1. Download latest and great WordPress stable version
2. Build website locally – get everything looking sweet within a XAMPP instance on my Mac.
3. Deploy website to a staging/test link – this is where the process gets messy. My deployment process at the moment is far from ideal and I’m sure it can be automated and streamlined. Anyway, this is what I currently do:
   1. Dumpy mysql DB .
   2. Zip local WordPress instance.
   3. Setup staging DB user/db.
   4. Import DB to staging server.
   5. FTP/SCP zip of WordPress instance. Unzip it on staging.
   6. Change wp-config.php DB connection details.
   7. Set WordPress permissions. (Normally running a dedicated php user pool under NGINX to avoid having to set world writable permissions and opening up nasty server security holes. See more in my nginx setup details.)
   8. Change a few paths in the DB to match staging URL.
   9. Login to WordPress.
   10. Install Search and Replace Plugin and run it to change all local paths to match staging paths. (This is a must have plugin for deployment!).
   11. Test on staging and ensure all paths are correct.

Problems with this process?

It’s too damn messy and long winded. There are too many paths in WordPress that are environment specific. If I recall from my Joomla development days, you never had to set more than one path in the Joomla config file when moving sites from server to server. The worst thing is that once I’m done on my staging version and want to move the site to production, I have to repeat the deployment steps above – this time going from staging to production. Then there’s things like environment specific files like .htaccess files, W3TC config options etc. You’ll also find the odd gem of a plugin that stores hardcoded paths in the DB that can’t be easily edited without lots of debugging to discover a hardwired path deep in some column in the DB. I love those plugins I do. As much as I love getting teeth pulled.

More deployment headaches

Let me complicate the situation even further. Let’s also assume that after the website goes live, the client (which is sometimes me!) wants some further development work completed. This might involve some new plugin installations, new custom post types, new widgets etc. – you get the idea. What now? Yes sure I can work away on my development instance on my local machine and get everything functionally tickety boo – but then it comes time to deploy to staging first for signoff and then finally into production. What are my options? Do I bring down a local copy of the live website – reset production paths back to local (which I do sometimes especially given the passage of time when maybe the client has added their own plugins [heaven forbid!]) or something else?

Then once I’m done making my updates – how do I deploy? Do I create a new staging instance (again repeating deployment steps) and finally another production instance (yip you guessed it – repeating deployment steps) or do I just separately go into the existing production instance and manually install new plugins directly in production (which could lead to production errors with minor plugin version differences etc.).

A Better WordPress Deployment Process

Of course it would be remiss of me to go off on this rant without offering some ideas for how to make this process better. Don’t get me wrong – I bloody love WordPress. I’m sure half my issues above are down to my own lack of understanding about how WordPress or any PHP/MYSQL app can be deployed more effectively. I’ve played around with Rails a bit in the past and love the deployment options Rails provides for pushing web apps into production using the likes of Heroku. (I see PHP Fog and Cloud Control are tauted as equivalents for PHP apps – wonder if it plays nice with heavy duty WordPress instances.) I also use Subversion for version control on my Mac and the main repository is stored online. I’m sure some wizard has worked out a better way to deploy to production using SVN commands. Please tell me how! Maybe Automattic could extend VaultPress to become a WordPress Deployment Manager in a kickass Heroku-like manner. I think this would be massive time saver for a lot of people and agencies who work with WordPress every day. If someone else wants to write this let me know – I’ll be your first beta tester!

Is Capistrano the Answer?

I vaguely remember Capistrano from the few bits of Rails code I’ve dabbled with in the past. It looks like some folks have leveraged Capistrano and Git to good effect to help with WordPress deployment. Here’s some interesting resources for anyone interested in this approach:

Deploying WordPress to SliceHost using Capistano and Git

WordPress Deployment with Capistrano 2 and git

How do you deploy WordPress?

I realise deployment headaches are probably not an issue for a lot of WordPress users – but I can see this becoming more and more of an issue as WordPress users get more advanced with time and as more and more developers flock to the platform as WordPress becomes more like an application framework. I’d love for you to share your WordPress deployment processes and even your deployment horror stories!