Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


Continuous Integration (CI) with automated test execution and trends have probably seen the broadest adoption. The ideas behind CI nowadays have changed the companies look at Build Management, Release Management, Deployment Automation, and Test Orchestration. This section provides best practices of Hudson - A Continuous Integration Solution to provide executives, business managers, software developers and architects a better sense of progress and code quality throughout the project lifecycle.

Hudson Best Practices

Always securing Hudson

This best practices is around authenticate users and enforce access control on Hudson instance
In the default configuration, Hudson does not perform any security check. This means any person accessing the website can configure Hudson and jobs, and perform builds. While this configuration is normally acceptable for intranet use and quick setup, it introduces high security risk like someone accidentally deleting your build jobs, reconfigure your job to run every minutes, kicking off too many builds at the same times, reconfigure your build instance...,etc.

Make use of fingerprint to resolve interdependency projects

When you have interdependent projects on Hudson, it often becomes hard to keep track of which version of this is used by which version of that. Hudson supports "file fingerprinting" to simplify this, so make best use of it.

The most reliable builds will be clean builds, which are built fully from Source Code Control.

To ensures a build can be reproducible, the build must be a clean build, which is built fully from Source Code Control. This practices also implies that all code including third-party jars, build scripts, release notes,...etc must be checked into Source Code Control.

Integrate tightly with your issue tracking system like JIRA or bugzilla to reduce the need for maintaining a Change Log

The integration helps to track changes as they are made, including build status, what build has been performed for this requirement or defects, and the link to the actual build results and artifacts.

Integrate tightly with repository browsing like FishEye if you are using Subversion as source code management tool

Repository browsing provides a quick update on what happens on a Subversion repository. It also provides a graphical diff on what changes have been made from the previous build.

Always configure your job to generate trend reports and automated testing when running a Java build

Trends helps project managers and developers quickly visualize current project progress status. Moreover, unit testing is often not to provide enough confidence that the delivered software complies to the desired quality. The more you test the software, the better the delivered software complies to the desired quality.

Setup Hudson on the partition that has the most free disk-space and backup Hudson Home regularly

Hudson needs some diskspace to perform builds and keep archives. All the settings, build logs, artifact archives are stored under the Hudson_HOME directory. Simply archive this directory to make a back up. Similarly, restoring the data is just replacing the contents of the Hudson_HOME directory from a back up.

Archive unused jobs before removing them

All unused jobs should be archived so it can be resurrect if the need arises.

Setup a different job/project for each maintenance or development branch you create

One of advantages of using CI tools is to detect problems early in the development lifecyle. Setup a different job/project for each branch you create will help to maximize the benefit of detecting problems early as part of supporting parallel development efforts and reducing risk.

Allocate a different port for parallel project build and avoid scheduling all jobs started at the same time

Multiple jobs running at the sametime often cause collision. Try avoiding scheduling all jobs started at the same time. Allocate a different port for parallel project build to avoid build collision.

Set up email notifications mapping to ALL developers in the project, so that everyone on the team has his pulse on the projects' current status.

Configure each person on the people list with his correct email address and what role he is currently playing.

Take steps to ensure failures are reported as soon as possible.

For example, it may be appropriate to run a limited set of "sniff tests" before the full suite.

Write jobs for your maintenance tasks, such as cleanup operations to avoid disk full problems.

Tag, label or baseline the codebase after the successful build.

Configure Hudson bootstrapper to update your working copy prior to running the build goal/target

  • No labels