Source control strategy for WordPress sites

My background is more in software and web application development, not website development. So when I started doing a few websites on the side, I wanted to translate some of the tools and processes that I use everyday as a developer to this new role. As I compared the different CMS options, WordPress was the winner in my eyes with a good balance of usability, maintainability, and customizability.

Having chosen WordPress, my attention shifted to finding a version control mechanism for the works in progress. The look and feel for WordPress sites are managed by themes. WordPress allows your to create a child theme based on an existing theme by assigning the ‘template’ property in the header for style.css (the only required file in a child theme). You can read more about creating a child theme here:

The content is maintained in the WordPress database (MySQL) and WordPress has a good mechanism for managing historical versions. The parent theme (in my case the new Twenty Eleven theme that came with WordPress 3.2) can be downloaded at any time, there’s no point in adding it to version control. Developing the child themes, I now have my handful of modified files under source control along with a simple FTP upload that serves as my deployment. Branching also works because I can deploy the branch to a 2nd theme folder (lets say ‘twentyeleven_custom_branch’) and preview the site with the new theme without actually activating the updated theme.

Setting up Cruise Control .NET 1.5/1.6 on Windows 7 + IIS7

I have been setting up a new continuous integration system on my laptop for some of my personal projects and thought it would be a good time to upgrade to Cruise Control 1.5. I came across some issues during the setup so I have put up my notes on the process in case anyone else has the same issues.
My Development Environment
Windows 7 (64-bit)
IIS 7.5
Cruise Control 1.6
Nant 0.86, Nant 0.91-alpha2
Visual Studio 2008, Visual Studio 2010
Installation Steps
  1. Download the installation package from
    • The release build of version 1.5 is available here on Source Forge.
    • The nightly build for version 1.6 is available here on CCNet Live.
  2. Run the installer. This will copy the files you need and create the IIS site/virtual directories needed to access Cruise Control .NET from your browser.
  3. Open your Internet Information Services (IIS) Manager (Start -> Run -> inetmgr )
  4. Create a new website point the site to <INSTALL PATH>webdashboard.
  5. Change the bindings for the new site to a unique port. ( I use port 90 and the CCNET is then accessed via http://localhost:90)
  6. Open the application pool created for this site and change the ‘Managed pipeline mode’ to ‘Integrated’.
  7. Open the services manager (Start -> Run -> services.msc) and start the Cruise Control .NET service.

Security& Permissions Issues

The default installation may cause issues due to permissions required to create folder (there are folders created on the fly for each CCNET project). It is best practice to have the CruiseControl.NET service running under a service account with proper permissions in the <INSTALL PATH>server and <INSTALL PATH>webdashboard  directories and subdirectories. The service account needs enough permissions to create new folders and files within the .server folder.


The new version of Cruise Control .NET has an admin dashboard that allows you to manage the plugins to display on the report pages. To enable the login, you need to modify /webdashboard/dashboard.config and add a password for the <administrationPlugin /> element.

As you install and uninstall the plugins, click the View Log button that appears next to the “Package has been installed” message to view the log of the installation. If there were any complications with the installation (usually permissions related), this log is your best source of information).

Visual Studio 2010 Unit Tests

The Visual Studio 2010 unit test results file has changed slightly from 2008. CCNET 1.6 addresses this issue.

Continuous Integration with Cruise Control, .NET (C#, WPF, ASP.NET) Projects, and NAnt

UPDATE: NAnt 0.91 Alpha 2 has been released with support for .NET 4. Download it here.
UPDATE: CruiseControl.NET 1.5 (Final) has been released and is available here.
UPDATE CruiseControl.NET 1.5 RC1 has been released and is available here.

My Cruise Control .NET implementation consists of numerous development projects each with multiple different Cruise Control .NET projects associated with it (one per environment per branch). In order to make the projects more maintainable, I have created a separate configuration file for each development project. Defining variables and separating ccnet.config configuration file into smaller files allows for easier maintenance of each project over their lifetimes.

Defining and using variables

Variables can be defined using the following format

<cb:define KEY=”VALUE” />

To reference that variable later in the configuration file, simply use $(KEY)

Check out the Cruise Control .NET website for complete explanation of variables using the pre-processor.

Separating the configuration files

<!DOCTYPE cruisecontrol [
<!ENTITY PROJECT_NAME SYSTEM “file:project.xml“>
<cruisecontrol xmlns:cb=”urn:ccnet.config.builder”>

project.xml would, then, contain the regular xml configuration for a Cruise Control .NET project:

<?xml version=”1.0″ encoding=”utf-8″?>
<project name=”My Project” category=”A Category”>
<intervalTrigger seconds=”900″ buildCondition=”IfModificationExists” />
<scheduleTrigger time=”04:00″ buildCondition=”ForceBuild” />
<labeller type=”svnRevisionLabeller”>
<pattern>Version {major}.{minor}.{build}.{revision}</pattern>
<sourcecontrol type=”svn”>
<cb:SvnOptions />
<xmllogger />
<cb:include href=”EmailConfig.xml”/>

On caveat with this idea is that changes to the separate configuration files are not recognized until the cruise control is restarted by either restarting the service or modifying the ccnet.config file.

Building and Deploying ASP.NET Web Applications

The NAnt target below is a full parameterized call to MsBuild.exe to compile any solution. ThoughtWorks.CruiseControl.MsBuild.dll provides an MSBuild logger that allows Cruise Control .NET to report the bulid output.

<target name=”build”>
<exec program=”${MSBuildPath}”>
<arg line='”${SolutionFile}”‘ />
<arg line=”/property:Configuration=${SolutionConfiguration}” />
<arg value=”/target:Rebuild” />
<arg value=”/verbosity:normal” />
<arg value=”/nologo” />
<arg line=’/logger:”C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll”‘/>


MSBuildPath – The path to the MsBuild executable.

For .NET Framework versions 2.0 and 3.5  on a 32-bit Windows OS, use C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MsBuild.exe
For .NET Framework version 4.0, use C:WINDOWSMicrosoft.NETFrameworkv4.0.30319MsBuild.exe

SolutionFile – The relative path from the build file to the solution file. Fully qualified paths are also allowed.

SolutionConfiguration – “Release” or “Debug”.