Automating WordPress Development and Deployment

1 Views

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.

Read More

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

Post Views: 1

Related posts

Leave a Reply

3 comments

  1. 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

  2. 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).

  3. 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.