Jenkins, build my software!

Orbital is going to be a big bit of software, with lots of things doing lots of other things. A big part of putting together such a large bit of software – alongside our Pivotal Tracker instance – is the regular process of ‘building’ the software from source code into something that can actually be used, testing it and getting it onto our development servers so that we can actually see what it’s doing. As part of Orbital we’re taking a step into what is a relatively unexplored frontier for the development team here at Lincoln – Continuous Integration.

Continuous Integration means that as we develop our software it’s constantly being built, tested and deployed to make sure that it’s behaving as expected. We’re using the popular Jenkins server to manage everything that’s going on as part of this process, as well as provide reports on what’s happened. We’re slowly adding more things to the list of what’s actually happening when the magic starts, but here’s what we’re going to be doing by the end of the project every single time that somebody makes a change to our codebase:

• Ensure that the source code is available from GitHub.
• Invoke Phing to do all kinds of additional goodness as part of an automated build, including:
  • Run unit tests on our code using PHPUnit.
  • Verify that the code adheres to certain style standards (We use the CodeIgniter Style Guide) using PHP Code Sniffer. Specifically we’re using Thomas Ernest’s implementation of the guide.
  • Run a whole battery of analysis that looks for messy code structure and duplicate code.
  • Automatically build the technical documentation using DocBlox. This isn’t the end-user documentation, but it does tell us exactly what all our code is supposed to be doing so that we have a reference.
  • Perform token replacement on the resultant codebase. This means that we can keep the code repository clear of all environment and institution specific configuration, since these are replaced as we perform a build.
• Deploy the built codebase to our development and testing platform so that we can actually use it.
• Tell us the results of all of the above in a variety of pretty graphs and reports.

The upshot of using a Continuous Integration system is that whenever we make a change to the codebase we can be a whole lot more certain that it hasn’t broken anything, as well as being confident that the code we’re releasing is clean, readable and well documented. Should anything go wrong we can see what and why within a few minutes of committing our code to the repository since we’re told exactly where the process has gone wrong.

Using this environment we’ve already identified a whole crowd of problems in things we’ve already written as well as in 3rd-party libraries that we use. As a result we can now go and fix these glitches and instances of bad design, and because they’re being monitored as we go we can actually see a trend on aforementioned pretty graphs of things getting better.

Eventually, when I’m done getting environments set up and I’m actually into hardcore coding mode, I’ll be putting together a simple information radiator which plots everything of note about the current iteration on a single graph, including open user stories, test acceptance rates, style error counts and so-on so that those involved in Orbital can see at a single glance if we’re on-track to finish our current iteration on schedule or if we need to focus our work differently.