WordPress and Drupal Deployment – the Dev, Stage, Production conundrum
One of the issues us as developers face daily is the concept of deployment. Especially with a CMS. Here’s an overview of some of the tools and approaches out there.
Deployment (or environment syncing of dev > stage > production) of a CMS/Website has the following components:
- Deploying code
- Deploying a database
- Running post deploy scripts.
Typically deployment is one way, from development to stage to production, although all the below can be performed in the opposite direction.
The following are some of the common methods of deployment:
Via (S)FTP or file syntonization – Old school
The old school method of deployment is by using scripts or manual process is to mirror dev, stage and production environments. Steps in this process involve manually exporting a database script and deploying that database to the staging or production environment. For files, they are copied directly to the staging/ production environment. Major drawbacks of this method are deployment tracking is lost and there is no easy rollback.
A newer and currently popular method for deploying website/CMS files is by using git. With a git deployment strategy, a git remote target is setup (either staging or production) and a git push is run whenever these environments need to be updated. This however only updates CMS files, and not a database. Post deploy hooks can be called on the target server to mimic database changes and run other commands via shell commands (run unit tests or clear caches). The added benefit of this approach is that deployments are tracked in git and can be rolled back easily.
Script based approach
Similar to a git deployment, a script based approach can be used for deployment to staging and production sites. This approach relies more heavily on POSIX shell commands (like rysnc, grep and diff). This requires more up front work for deployment, but is much more customizable and ultimately powerful. A combination of a script based approach and git deployment are common in the WordPress and Drupal worlds for deployment.
A more robust build system can also be implemented. In a CI type environment, a combination of unit tests, code review, VCS and deployment can all be rolled into one. More robust and powerful than a script based approach, a CI deployment plan is almost bulletproof as most (Travis CI, Jenkins) mandate testing of code before passing a build. This approach requires the setup of a dedicated CI server that has hooks into the VCS (git, svn etc.) and still requires the integration of shell scripts to fully take advantage of.
More than scripts but less that full-fledged CI systems are some tools that can be used to deploy and sync WordPress and Drupal sites.
Capistrano is a Ruby based tool that became popular with the Ruby on Rails crowd as a way to deploy code. Similar to a git deployment process, Capistrano allows for command line deploys and post deploy hooks but allows for a robust roll-back feature. Capistrano is configured via config files and has a requirement that both host and target are running Ruby.
Drush is the Drupal-shell that allows for running command line scripts specifically on a Drupal codebase. Many things like installing modules, setting up sites and themes, basic database versioning to basic deployment via rsync, can be accomplished by Drush.
Another tool similar to Drush is wp-cli. A super powerful command line tool for managing WordPress, wp-cli does for WordPress what Drush does for Drupal. Custom commands can also be written to hook into custom code, themes and plugins. Cool.