As a relatively new project, Deft has a small code base and only a few developers. This provides the perfect opportunity to implement a decent build environment, before things become too involved and problems ingrained. To my own mind, any team-oriented development environment needs to cover the single developer onward to the final deliverable and I see three key requirements: continuous integration; continued feedback; continual imposition.
Possibly the simplest of these to get right is continuous integration, by which I mean that all developer changes merged into a given branch are built as part of the whole with minimal delay and alongside all automated tests. At the core of this process is the build server, and we chose to use Jenkins (née Hudson) as it is breeze to install and – either internally or through available plug-ins - provides all the functionality a development team could need, up to and including Chuck Norris. Nice features for example include automatic installation of Java and Maven as needed by the build, and specific to that build task to facilitate isolation from the server on which it is running. Installing Github connectivity through a plug-in was essential, and handled like all plug-ins through the application with nothing more than a couple of clicks and a restart. Following this I considered necessary only EMail-Ext, which helps ensure that notification emails sent contain useful information other than “the build is broken; fix it”, and Sonar*.
If you are unfamiliar with Sonar then I would urge you to follow the link at take a look. This platform collects varying metrics from the build and provides analysis on a per-build and continuing basis, and is highly extensible in the information that can be produced with everything from total lines of code to estimated cost of current technical debt. With Jenkins feeding data to this application every time the Sonar-specific build is successfully run, the second criterion of continued feedback is satisfied. All developers can see at a glance what state the application is in, and how that compares to any other build in the history. As the number of developers grows, and the code base with it, this kind of analysis can prove invaluable in identifying problem areas be they current or upcoming and in helping keep a steady hand on progress. One of the many metrics available is an analysis of violations based on the results of Checkstyle, and it is this tool that provides the primary satisfaction of the third requirement – continual imposition.
Whilst Checkstyle will report violations during the build as configured, it can also be applied directly within many popular build environments to ensure that developers are informed that their code is in violation of standards before they commit. Of course, Checkstyle is not the only useful tool here and in any case the standards need to be firstly developed… but that can wait a little while yet.
The build server is here, although there’s not much to see for the tourist at time of writing.
* Actually, Jim Petersson was unhappy with Jenkins’ blue balls (who is happy with blue balls?) and considered the Green Balls plug-in essential.
Comments are closed.