Continuous integration with Hudson
Open source CI server offers easy setup and configuration
Continuous integration has become common practice for teams focused on ensuring code quality throughout the software development
lifecycle. In this article, Nicholas Whitehead introduces Hudson, a popular open source CI server. Learn how to set up a Hudson
server in your application development environment (examples are given for Windows XP with Tomcat 6 or Ubuntu Linux with JBoss
AS), get an overview of the many configuration options Hudson provides, then implement an automated build, test, and reporting
process for an example project. Level: Beginner
Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development
teams with the following challenges:
- Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in
response to a specified event. If you want to build a software artifact from source, your build process is not bound to a
specific IDE, computer, or person.
- Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that
while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that
the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to
- Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined
tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested
parties, indicating that a build or some tests have failed.
- Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification
and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running
environment or to a software repository. In this way artifacts can quickly be made available to users.
To implement a CI server you need, at minimum, an accessible source code repository (and the source code in it), a set of
build scripts and procedures, and a suite of tests to execute against the built artifacts. Figure 1 outlines the basic structure
of a CI system.
Figure 1. Basic structure of a CI system
The system components come into play in the following sequence:
- Developers check new and modified code into the source code repository.
- The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved
from the repository into this workspace, where the build is then executed.
- The CI server executes the build process on the newly created or refreshed workspace.
- Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails,
registered individuals can be notified by email, instant messaging, or some other method.
- If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server)
and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could
be an external repository, such as a file server or a software distribution site like Java.net or SourceForge. The source
code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any
formal source control system at all.
- CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued
for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.
Hudson: A continuous integration server
Continuous integration has grown in popularity over the past several years and today you have quite a few CI servers to choose from, both commercial
and free. I personally had used four CI servers before a colleague recommended that I look at Hudson. I was immediately impressed by it. While I initially assumed that Hudson was not well known, a survey at the Java Power Tools site shows it as the most widely used CI server among respondents, garnering (at time of this writing) 37.8 percent of all votes.