Automating Wordpress Development and Deployment

Here is how I ended up solving this issue so far:

Source code directories:

build/ - build files for phing and environment-specific properties files    build.xml    src_qa.properties - properties to use the qa server as the source for a deployment    dst_qa.properties - properties to use the qa server as the destination for a deployment    etc... for other environmentsconf/ - contains environment specific configuration files, each in a subfolder named after the environment    dev/        db-config.php - config file for HyperDB - http://codex.wordpress.org/HyperDB        default - Apache conf that holds ServerAlias configs for multi-site WordPress        hosts - useful for developers to redirect their browser to various domains in different environments        htaccess.dist - for WPMU        httpd.conf - main Apache config file, specific to each environment        my.cnf - mysql config file        wp-config.php - main wordpress config file    qa        (same as dev/ but with different values in each file)    staging        (same as dev/ but with different values in each file)    prod        (same as dev/ but with different values in each file)src/ - wordpress source code    wp-admin/    wp-content/        mu-plugins/        plugins/        themes/     wp-includes/test/ - holds WP test suite and custom tests for plugins, themes, etc...

I am using Hudson CI Server (http://hudson-ci.org/) to to automated and manual builds using subversion checkout tasks, phing, and phpunit, etc... Basically, the Hudson server pulls code from subversion depending on what you want to deploy, and it rsync's the files to be deployed from the CI server out to the destination server.

Or, in the case of a deployment from staging directly to production, Hudson rsync's the files from staging, down to the CI server, and then back up to production.

I have build jobs setup in hudson for the following pieces of functionality:

core WP code - deploys core WP files and mu-plugins from src to dst    svn to qa    svn to staging    staging to prodWP plugins/ folder - deploys only the plugins folder     svn to qa    svn to staging    staging to prodWP themes/ folder - deploys the entire themes folder    svn to qa    svn to staging    svn to prodSpecific themes - deploys a specific theme (chosen through a drop down during the build process using Hudson's parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build)    svn to qa    svn to staging    svn to prod

The hudson jobs also have the ability to deploy environment specific PHP files (e.g. wp-config.php, db-config.php), as well as Apache and MySQL config files to the proper locations on each server. In some cases, we deploy to multiple web servers, and multiple database servers, and most of the build configuration is taken care of through the phing build file and the .properties files mentioned above.

In the future, when we have a development integration environment, we will probably do automated deployments upon svn checkin of any code.

This setup allows different developers in the organization with different skillsets (CSS/HTML vs. PHP mainly) to work separately and get their code changes out to the proper environments quickly without involving a bunch of unnecessary people. Hudson allows me to lock down different deployment jobs so only the right people have access to configure them and kick them off.

That's kind of a high level overview of what I have setup, let me know what you think. The biggest annoyances with this setup was keypairs, user accounts, and file permissions with rsync across all the different servers.

Dave

For the filesystem we use GIT and it works very well. You can have a branch for each team member and then merge it into the production branch. We can keep our code integrated whitout any troubles.

For the database I keep dumping the prod database and sharing with everybody (you can even send it to the GIT repo and then everyone will have the lastest dump).

I found rollout to be quite usefull. Its a paid service but its worth trying. No Scripting No coding at all. Just signup and follow the recipe out there. You are done. Also it does pre deployment checks that makes your deployment quite smooth and easy.