A recent article published in IBM developerWorks talks about automating the Continuous Integration (CI) and Code Inspection tasks in a build process using open source tools. It explains how to install and configure Hudson, a CI server developed by java.net community, to poll a Subversion code repository and run an Ant build script anytime a change is detected in the source code.
The author Andrew Glover lists the following items as the three main components in a typical CI environment setup:
- An automated build process with a build tool like Apache Ant.
- A source code repository like CVS or Subversion.
- A CI server such as Hudson.
Andrew uses a sample java application to show how to configure a java project in Hudson server for running automated builds. He also shows how to integrate code analysis and software inspection tools like FindBugs and PMD using Hudson's plug-in extensions.
The article explains how to use Hudson to capture the build process execution times and test trends. For each build, the CI server will parse the JUnit result XML files and build a trend graph showing how many tests were added between each application build. It also shows if the tests are passing (blue graph) or failing (red graph). The code violations or defects found using PMD and FindBugs can be tracked in each build for historical analysis.
Hudson can be configured to point to a SMTP server to send e-mails to the project team when the build fails. It also supports RSS as a notification mechanism so the team can subscribe to the project's Build Status page via RSS feeds.
Hudson has support for both JUnit and TestNG testing frameworks. It can also be integrated with SCM software such as CVS, ClearCase or Accurev and build tools like Maven or Gant. A full list of plugins on Hudson website shows its integration with different open source and commercial SCM, code coverage, and issue tracking tools.
In another article in developerWorks on the CI topic, Paul Duvall presents some best practices when setting up a CI environment and how to avoid, what he calls, the CI anti-patterns. These best practices are:
- Developers should commit smaller chunks of code frequently rather than waiting for a long time and checking-in several changes at once.
- CI server should notify the project team immediately when the build breaks.
- It should use the feedback mechanisms like E-mail or RSS to communicate build status to the project team.
- Build status feedback should be succinct and it should only contain relevant information about the build.
- Build server should have sufficient hardware resources for faster builds.
- The project team should follow a "build pipeline" approach to execute longer-running processes asynchronously.