Has anyone ever worked on a WordPress project with multiple developers in different locations? Are there best practices around distributed development teams and automated deployments?
I have a team of varying degrees of developers, including plugin developers, theme developers, and simple CSS style tweakers, in a few different locations, and I would like to setup a good system for everyone to be able to work on their separate pieces and continuously deploy changes without disturbing anyone else's code.
The system is running an installation of WordPress-MU at the moment, and it will eventually be upgraded to 3.0. Ideally, we would store the themes and plugins in source control, and since a few modifications have been made to the core WordPress code, it has to go into the repository as well. I'm having trouble figuring out the best way to structure the repository and do controlled but somewhat automated deployments.
How do you handle working in and deploying to development, testing, staging, and production environments, when different types of plugins and themes may store configurations on the file system or in the database? I realize the answer may be "Don't use WordPress," but assuming I have to, let me know what you think,
Thanks for your help,
Dave
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 environments
conf/ - 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 prod
WP plugins/ folder - deploys only the plugins folder
svn to qa
svn to staging
staging to prod
WP themes/ folder - deploys the entire themes folder
svn to qa
svn to staging
svn to prod
Specific 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