Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Hudson-ci/Hudson Best Practices

Hudson Continuous Integration Server
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse Source
Hudson-bust.png Hudson Best Practices











Introduction

Continuous Integration (CI) with automated test execution and trends has changed the way companies look at Build Management, Release Management, Deployment Automation, and Test Orchestration. This section describes Hudson best practices in order to provide executives, business managers, software developers and architects a better sense of what Hudson can contribute throughout the project lifecycle.

Hudson Best Practices

Idea.png
Always secure Hudson.
This best practice is around authenticating users and enforcing access control on a 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 risks, like someone accidentally deleting your build jobs, reconfiguring your job to run every minute, kicking off too many builds at the same time, reconfiguring your build instance, etc.
Idea.png
Backup Hudson Home regularly.
Enough said.
Idea.png
Use "file fingerprinting" to manage dependencies.
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.
Idea.png
The most reliable builds will be *clean builds*, which are built fully from Source Code Control.
To ensure a build can be reproducible, the build must be a clean build, which is built fully from Source Code Control. This practice implies that all code is checked into Source Code Control.
Idea.png
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.
Idea.png
Integrate tightly with a repository browsing tool 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.
Idea.png
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.
Idea.png
Set up Hudson on the partition that has the most free disk-space
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.
Idea.png
Archive unused jobs before removing them
All unused jobs should be archived so they can be resurrect if the need arises.
Idea.png
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. Setting up 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.
Idea.png
Allocate a different port for parallel project builds and avoid scheduling all jobs to start at the same time
Multiple jobs running at the same time often cause collisions. Try to avoid scheduling all jobs to start at the same time. Allocate a different port for parallel project builds to avoid build collisions.
Idea.png
Set up email notifications mapping to ALL developers in the project, so that everyone on the team has his pulse on the project's current status.
Configure each person on the people list with his or her correct email address and what role he or she is currently playing.
Idea.png
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.
Idea.png
Write jobs for your maintenance tasks, such as cleanup operations to avoid disk full problems.
Idea.png
Tag, label, or baseline the codebase after the successful build.
Idea.png
Configure Hudson bootstrapper to update your working copy prior to running the build goal/target

Back to the top