Hudson is an open source Java-based web application that executes and monitors jobs. These jobs are typically builds that may produce test results and/or build artifacts. Hudson is maintained as two separate projects: the Hudson core and the Hudson plugins. Hudson core is the web application with several key plugins and is maintained by core Hudson committers. Hudson plugins provide additional functionality to Hudson and are maintained by other Hudson community members.
Hudson was first designed as a continuous integration server, a fact that is still evident in the project's web address: http://hudson-ci.org. Continuous integration is one of the practices in Extreme Programming. The goal of continuous integration is to identify and resolve integration problems early in the development process instead of later, when they are more difficult to resolve. Similarly, Hudson can be used for continuous deployment, which can help identify and resolve deployment problems early in the development process. By identifying integration issues earlier in the development process, the software design can be improved and problems can be dealt with before they grow even more difficult to resolve.
Test-driven Development is another one of the practices in Extreme Programming. By ensuring that a project follows the Test-driven Development practice or, at the very least, has sufficient test coverage, Hudson can provide feedback in the form of test reports and notifications if a build or test fails.
Analysis of the project code can be accomplished using Checkstyle, PMD, FindBugs, and Sonar plugins. These plugins ensure that the project follows the defined coding conventions and detects common bugs in the application's source code. Having the project code follow common coding standards makes the code easier for new team members to understand and easier to maintain. Finding and fixing software defects is much easier and less time consuming earlier, rather than later in the development process.
The build process can, over time, become very large and complicated with many steps. A common problem that can arise is that a build will work on one developer's computer, but not on another's. A Hudson job can be seen as a formalization of the build process. The Hudson job creates build artifacts at scheduled times or manually, based on the user request. Having the build process formalized forces the IT team to keep it up-to-date with any changes in the application that is being developed. This creates a build that is repeatable and portable and removes the "but it builds on my computer" problem.
Plugins for the deployment of build artifacts to an application server and publishing them to a repository are available. Using these plugins, the deployment process can also be formalized and automated. This will allow users to identify and correct deployment issues early in the development process.
There are many roles in a typical Information Technology organization and there are four that can benefit from the adoption of Hudson: the project manager, the software developer, the tester, and the application server administrator. Depending on the size of the IT organization, these roles may span multiple departments or a single person may have more than one role. If the IT organization is large, with these roles functioning in different departments, Hudson can be the tool that brings these teams together to work toward the common goal of creating great software.
Hudson provides the project manager with a dashboard overview of the project(s) they are responsible for. They can see the build status and history, as well as view test reports and test coverage, giving them the confidence that the project is healthy and moving forward.
Getting quick feedback via the unit test reports and the build status that Hudson provides helps assure the software developer that they have not broken any existing code and that any features and/or bug fixes they are working on have not broken the build. Removing the burden of building the software for deployment allows the developer to focus on providing value to the customer by developing and improving software, instead of worrying about building and releasing the software.
The tester can benefit from using Hudson by automating some of the testing using the Selenium plugin and by viewing the test reports, which eliminates much of the mundane and repeatable part of testing. Having builds available early and often will also help the tester get a head start on developing tests and actually beginning some testing.
The application server administrator can benefit from using Hudson because continuously building and deploying the application will improve their confidence in the build process and reduce the risk of unpleasant surprises at the last minute. Hudson defines the build very clearly and this helps make the build repeatable and portable, which removes the requirement to manually build the application from the administrator.
One of the strengths of Hudson is its flexibility to extend itself using plugins. There are many useful Eclipse and community-supported plugins that extend Hudson's basic functionality. We can also extend Hudson's functionality ourselves by writing our own plugin.
Hudson integrates with many existing development, testing, and build tools commonly used by IT organizations. This integration allows developers and testers to work with the tools that they are familiar with and also to utilize the additional capabilities that Hudson provides. Some of the tools Hudson integrates with are: Git, SVN, CVS, Ant, Maven, Gradle, JUnit, TestNG, Selenium, Checkstyle, PMD, and FindBugs.
Hudson also provides a RESTful API to allow other systems access to its functionality. The API can be used for functions, such as retrieving Hudson results, triggering a new build, or creating a new job.
Hudson was created by Kohsuke Kawaguchi at Sun Microsystems as an open source continuous integration server and had its first release in February 2005. By 2008, Hudson had started to become a popular alternative to other continuous integration servers and won a Duke's Choice Award in the Developer Solutions category at Java One in May 2008.
Oracle completed the acquisition of Sun Microsystems on January 27, 2010, which included ownership of the Hudson trademark and its intellectual property. Disagreements between Oracle and Kohsuke and other project contributors over project infrastructure and trademark control began in November 2010 and ended in February 2011 with the renaming (forking) of the Hudson project to a new project named Jenkins.
In May 2011, Oracle began the process of transferring the Hudson project and trademarks to the Eclipse Foundation. The Hudson project was moved to the Eclipse Foundation and became a full Eclipse project on December 12, 2012 with the release of Hudson 3.0.0.
In this chapter, we have covered what Hudson is and how it can benefit an IT organization. We have also seen how Hudson can benefit different roles in an IT organization. We've covered the history of Hudson and what types of tools it can leverage. In the next chapter, we will walk through how to install and configure Hudson, so we can begin using it to improve our software projects.