Over the past few months I’ve been working on a community component for the WRDS web site. The project is based on WordPress but it’s a bit more complicated than a typical WordPress blog. First off, we’re using BuddyPress, an extensive WordPress plugin that touts itself as “Social networking in a box.” The plugin adds social networking features like user profiles, user to user messaging, groups, Twitter style short messaging, and a pool of complementary socially oriented plugins. In addition to third party plugins, we’re developing a few of our own custom plugins and a custom theme that matches our web site design.
That’s a lot of moving parts. Keeping track of the source code for all of these components could become a headache pretty quickly. I wanted to make sure I had a good workflow in place before getting too deep. The workflow would need to handle updates to WordPress, BuddyPress and other plugins, as well as our own internally developed plugins and theme.
My goals for source control on this project:
- A single code line should provide everything needed to run the project short of configuration data.
- Isolate our custom plugins and theme so that they can be usable outside of this project.
- Code should be deployable with minimal manual intervention, ensuring quick turnaround getting new features in front of our team for feedback as well as making it easy to setup and maintain hosts.
One of the nice things about WordPress is that it’s extremely easy to spin up on a development machine. Since this was a fresh project that I’d be developing locally, I took the chance to use Git for source control. It’s proven to be extremely flexible for the needs of this project.
WordPress can update itself. But in a distributed environment with a few app servers, I’d like finer grain control over deploying updates. With this in mind I decided to store WordPress’s codebase as part of my source code.
After some research, I settled on making the standard WordPress code the main branch of the project. Then I created a second working branch from the master WordPress line to track all customizations. I add all third party plugins, BuddyPress customizations, and so on to this working line. The working branch is where I do most of my day to day commits. It can be cloned by any another developer or to a server as a functioning copy of the site.
Whenever new WordPress updates are released I switch to the master branch, delete the existing code, apply the new code, commit the new code changes, and tag the branch with the new version number. Then I switch back to the working branch and merge in new WordPress updates.
Custom plugins & theme
Git supports embedding external repositories within a repository. Embedded repos are called submodules. Submodules lend themselves well to custom WordPress plugins and themes, allowing me to maintain separate histories for each. The parent project maintains pointers to a specific version of each submodule. Git submodules are somewhat analogous to svn externals.
With all my code tracked, setting up a new server is as simple as running
git submodule init, and
git submodule update for the working code branch. After that, I can update any instance of the site with the latest changes by running a
git pull origin working and
git submodule update.
While that’s nice, that still required ssh’ing into the remote servers. I was able to automate deployment a step further. But I’ll save details on that for another post.