What is Hudson?
Hudson monitors executions of repeated jobs, such as building a
software project or jobs run by cron. Among those things, current Hudson
focuses on the following two jobs:
- Building/testing software projects continuously, just like
CruiseControl or DamageControl. In a nutshell, Hudson provides an
easy-to-use so-called continuous integration system, making it easier
for developers to integrate changes to the project, and making it easier
for users to obtain a fresh build. The automated, continuous build
increases the productivity.
- Monitoring executions of externally-run jobs, such as cron
jobs and procmail jobs, even those that are run on a remote machine. For
example, with cron, all you receive is regular e-mails that capture the
output, and it is up to you to look at them diligently and notice when
it broke. Hudson keeps those outputs and makes it easy for you to notice
when something is wrong.
Features
Hudson offers the following features:
- Easy installation: Just java -jar hudson.war, or deploy it in a servlet container. No additional install, no database.
- Easy configuration: Hudson can be configured entirely from
its friendly web GUI with extensive on-the-fly error checks and inline
help. There's no need to tweak XML manually anymore, although if you'd
like to do so, you can do that, too.
- Change set support: Hudson can generate a list of changes
made into the build from CVS/Subversion. This is also done in a fairly
efficient fashion, to reduce the load on the repository.
- Permanent links: Hudson gives you clean readable URLs for
most of its pages, including some permalinks like "latest build"/"latest
successful build", so that they can be easily linked from elsewhere.
- RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
- After-the-fact tagging: Builds can be tagged long after builds are completed
- JUnit/TestNG test reporting: JUnit test reports can be
tabulated, summarized, and displayed with history information, such as
when it started breaking, etc. History trend is plotted into a graph.
- Distributed builds: Hudson can distribute build/test loads
to multiple computers. This lets you get the most out of those idle
workstations sitting beneath developers' desks.
- File fingerprinting: Hudson can keep track of which build
produced which jars, and which build is using which version of jars, and
so on. This works even for jars that are produced outside Hudson, and
is ideal for projects to track dependency.
- Plugin Support: Hudson can be extended via . You can write plugins to make Hudson support tools/processes that your team uses.
Hudson Best Practices
Continuous Integration with automated test execution has seen broad
adoption in recent years. The ideas behind Continuous Integration have
changed how companies look at Build Management, Release Management,
Deployment Automation, and Test Orchestration. This section provides a
set of best practices for Hudson - A Continuous Integration Solution to
provide executives, business managers, software developers and
architects a better sense of the development progress and code quality
of projects throughout the development lifecycle. ()
Introductory Articles
Test Drive
Launch Hudson through Java Web Start for a test drive. Once it launches, visit
to get to the dashboard. Any configuration that you do with this Hudson
will be stored in ~/.hudson, so your data will survive through Hudson
process restart.
Installation
To run Hudson, minimally you need to have JRE 1.5 or later. After you , you can launch it by executing java -jar hudson.war. This is basically the same set up as the test drive, except that the output will go to console, not to a window.
Alternatively, if you have a servlet container that supports Servlet
2.4/JSP 2.0 or later, such as Glassfish, Tomcat 5, JBoss, Jetty 6, etc.,
then you can deploy hudson.war as you would any WAR file. See this document for more about container-specific installation instruction.
Once the war file is exploded, run chmod 755 hudson in the exploded hudson/WEB-INF directory so that you can execute this shell script.
If you're running on Windows you might want to run Hudson as a
service so it starts up automatically without requiring a user to log
in. One way is to first install Tomcat as a service and then deploy
Hudson to it in the usual way. Another way is to use the .
However, there may be problems using the service wrapper, because the
Main class in Hudson in the default namespace conflicts with the service
wrapper main class. Deploying inside a service container (Tomcat,
Jetty, etc.) is probably more straightforward, even for developers
without experience with such containers.
Also, see how other people are deploying Hudson to get some idea of how to make it fit your environment.
阅读(2140) | 评论(0) | 转发(0) |
