Hudson_WhitePaper

Hudson Continuous Integration Server
Author: Farrukh Jalil| Copyrights MAZARS Consulting Pakistan 1
White
Paper
Introduction
Hudson is a powerful and widely used open source continuous integration server providing
development teams with a reliable way to monitor changes in source control and trigger a variety of
builds. Hudson excels at integrating with almost every tool we can think of. Use Apache Maven, Apache
Ant (or anything we can start with a command line script) for builds, and send messages via email, SMS,
IRC, and Skype for notifications. In addition to providing a platform for continuous integration builds,
Hudson can also be extended to support software releases, documentation, monitoring, and a number
of use cases secondary to continuous integration.
With continuous integration, the system completes a build, test, deploy, and integration in response to
every single commit. If a developer in the web application group checks in code, Hudson kicks off a
build, runs unit tests, deploys the code to a new server, and performs a set of integration tests. If this
build fails or the tests encounter an unexpected condition, everyone is notified of this failure. With
continuous integration, no one needs to drop everything and run a release build, these builds are
generated every single day, and in the most mature environments, a fully tested and verified system can
be deployed to production at any time. In other words, when we automate build, test, and verify using a
tool like Hudson we can continue developing our applications without having to wait (or synchronize) on
some manual builds, test, and verify process. Making these processes automatic has another important
side-effect; it makes the development process more scalable. When our teams don’t have to stop to
actively test and collaborate with one another, it is much easier to add additional developers to a
project. Without continuous integration we have to stop and synchronize release schedules. With
continuous integration we can reduce the risk associated with a particular software development cycle.
Key Features of Hudson
The key features of Hudson are below
 Easy installation
 Easy configuration
 Web based interface
 Distributed Builds
 Unit test Reporting
 File Fingerprinting
 Build status Notification
 Extendable with plug-ins

White
Paper
Products supported by Hudson CI Server
Hudson supports hundreds of standard products via plug-ins. To name a few
 SCM vendors: Git, CVS, SVN, Perforce, Mercurial, Team Foundation
 Build tools: Ant, maven, Gradle, MSBuild, Nant, Rake
 Unit Testing frameworks: JUnit, NUnit, Selenium, CppUnit, TestNg, XUnit
 Code Coverage tools: Clover, Cobertura, Emma, Serenity, Sonar, NCover, Jacoco
 Code Analysis Tools: Checkstyle, PMD, Dry, Findbugs, Warnings, CCM, Violations
 Security Tools: LDAP, Active Directory, Crowd, OpenID
 Applications servers: Weblogic, Glassfish, Tomcat, JBoss, IIS, JRebel
 Virtual Environment: EC2, Virtual Box, VmWare, JCloud
 Social communication: E-mail, IRC, Jabber, SMS, Twitter
Continuous Integration Stakeholders

White
Paper
Steps for Hudson configuration and job creation
Below are the steps for Hudson installation and a build job example
Step 1: Install and configure Hudson CI Server
1. Download the latest hudson.war file from http://hudson-ci.org
2. Login Glassfish server admin console and deploy the hudson.war

White
Paper
3. Open web browser for launching the Hudson CI Server using link (http://host-IP:port/hudson).
Hudson CI Server Initial Setup screen appears with different plug-ins, press the buttons “Install”
and “Finish” to complete Installation
INFO: “The required plug-ins can be installed during initial setup or user can install/update after
installation in Manage HudsonManage Plug-ins section.”
4. After completing installation, click “Manage Hudson” link on left menu for configuration

White
Paper
5. In Manage Hudson, click the option “Mange Plug-ins” to install plug-ins
There are four tabs present in this option click the tab named “Available”.
In “Available” tab, click the option named “Recommended”, select above plug-ins and Press
“Install” button present on the page bottom.
The required plug-ins are;
a. Deploy to container plug-in (Artifact Uploaders Header)
b. Email-ext plug-in (Build Notifiers Header)
c. Backup plug-in (Utilities Header)

White
Paper
6. Again, click on “Manage Hudson” link on right-side and go for the “Configure System” option
7. In “JDK Installation” section enter the JDK name and path of installation folder or click the
checkbox “install automatically”
8. In “Ant Section” type Ant name and ANT_HOME or click the checkbox “install automatically”

White
Paper
9. In “Email Notification” section fill the SMTP configuration i.e. SMTP server, System Admin Email
Address, Hudson URL, User Name, Password, and SMTP Port. If configuration requires SMTP
authentication, click the checkbox “Use SMTP Authentication”
10. Press “Save” button to save configuration
Now, the Hudson configuration has been completed successfully. We are ready to create build if we
have ANT/Maven scripts for applications

White
Paper
Step 2: Creating Ant scripts for application build
NetBeans maintains Ant script files for creating and deploying build file. These Ant scripts are required
to modify/change for working with Hudson CI Server. We can locate all Ant script files in nbproject
folder for update or modification.
1. Files hierarchy for calling Ant script in NetBeans is
build.xmlbuild-impl.xmlant-deploy.xml
2. Different properties files are used in above Ant scripts
including nbproject/project.properties,
nbproject/build.properties, and
nbproject/private/private.properties
3. For making independent build process we have to copy
all dependencies i.e. jar files, JDBC drivers and scripts to
a separate folder and modify the above properties files
with the path reference of that folder. (In our case all
dependencies are copied in “nblib” folder)
4. After copying all dependencies and references in
properties files, commit the newly created folder, Ant
scripts, and properties files in SVN repository.
Note: Make sure that folders named “dist” and “build”
should not be included in committed source in SVN.
There are different targets present in “build-impl.xml” file used to execute independent parallel tasks in
build process. We have a requirement to copy each war file in a separate backup folder after execution
of build process.
Note: The archive.dir, backup.war.name, and backup.war.extension will define in “project.properties”
file.

White
Paper
Step 3: Creating job for build automation
1. On left-side menu click on the option “New Job” and enter Job name for application build. Select
“Build a free-style software job” and press the OK button
2. Newly created job will be display in main dashboard without any information or response i.e.
N/A. After creating new job we will configure it by clicking on job name

White
Paper
3. On left-side menu, click on “Configure” option for add/modify configuration
4. In “Source Code Management” section, select “Subversion” and enter “Repository URL”, “Local
module directory” (Name of the folder where source check-out from SVN in workspace), and
“Checkout-out Strategy” (SVN update)
5. If there is a requirement for scheduled build, triggered on a specific time. We have to configure
“Build Triggers” section. Click on the checkbox “Build Periodically” and enter the schedule using
CRON expression

White
Paper
6. If a build stuck, we can set timeout minutes with mark it as a fail build
7. Select Ant version in “Build” Section
8. In “Post-build Actions“section, select “Email Notification” and enter recipients email address.
9. For deploying application war file to a application server, we can select the option “Deploy
war/ear to a container”.
a) Enter relative path for created war file in distribution folder
b) Select App. Server from “Container” dropdown, in our case we select Glassfish 2.x
c) Enter admin User/Password
d) Enter complete path App. Server folder
e) Enter admin port for the application server, in our case the port will 4848
f) Enter Hostname/IP of the computer on which App. Server installed

White
Paper
10. Select checkbox “Edit Email Notification” and enter email recipients with message detail. We
can add email triggers for build failure/success
11. Click “Save” button at the end to save the configuration
Now, we are ready to execute our build job by clicking the icon on right-side.
We can see the execution status on the bottom left of the screen.

White
Paper
Popular Hudson Competitive Offerings
Apache Continuum — continuous integration server supporting Apache Maven and Apache Ant (open
source)
Bamboo — commercial continuous integration server by Atlassian Software Systems
CruiseControl — Java-based framework for a continuous builds process (open source)
TeamCity — commercial continuous-integration server by JetBrains
Team Foundation Server — commercial continuous integration server and source code repository by
Microsoft
Tinderbox — Mozilla-based product (open source)
Rational Team Concert — commercial software development collaboration platform by IBM
Further Reading
For more information read Hudson book available on http://www.eclipse.org/hudson/the-hudson-
book/book-hudson.html

Hudson_WhitePaper

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Hudson_WhitePaper

Similar to Hudson_WhitePaper (20)

Hudson_WhitePaper