Continuous integration with Hudson

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 interdependent components.
• 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:

1. Developers check new and modified code into the source code repository.
2. 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.
3. The CI server executes the build process on the newly created or refreshed workspace.
4. 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.
5. 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.
6. 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 is a free and open source product hosted at Java.net It was originally written by Kohsuke Kawaguchi, a staff engineer at Sun Microsystems, who announced its release on his blog in February of 2005. Hudson has since had approximately 154 releases.

Here are some of the reasons why I like Hudson, and why I would recommend it to you, barring any unusual requirements:

• Of all the CI products I've used, it is by far the easiest to install and configure.
• Its Web-based user interfaces are very friendly, intuitive, and responsive, in many cases providing immediate Ajax-enabled feedback on individual configuration fields.
• Hudson is Java-based (which is useful if you're a Java developer) but is not limited to building Java-based software.
• Hudson is cleanly componentized and offers a well-defined and documented extensibility API in the form of Hudson plugins. This has in turn led to a large library of Hudson plugins that extend the functionality of the server; these are freely available and installable from the Hudson console.