Adrián Deccico

After researching and learning about Continuous Integration I start evaluating available free CI servers. I tried to be impartial, even though I was tempted to start using CruiseControl, mostly because of Martin Fowler article about Continuous Integration. Next to analyzing an independent feature matrix, I decided to try by my own the three best options, which were the famous CruiseControl, Continuum from Apache, and the (by that time) unknown Hudson…

My plan was simple, just setting up a hello world task connected with CVS which was the SCM that my company was using at that time. After my test, the decision was very clear, Hudson not only offered an incredibly nice UI where everything can be set up from the web without need to configure XML files (like in Cruise or CruiseControl) but truly multiplatform, a “live” console session, and distributed load balancing.

Summing up the advantages:

• Easy to execute: “java -jar hudson.war”
• Easy to configure: Everything is accessible from a web.
• User friendly. They don’t need to be engineers.
• Make a job, and use it always. (Copy jobs)
• Executing options: Chaining, Parametrization, SCM ant Time triggering.
• Jobs triggering: SCM, Time and from a remote script.
• Changeset visualization (from any SCM)
• Notifications (RSS, mail, systray, Twitter!)
• Auto testing (NUnit, JUnit, builds ad-hoc)
• Load balancing (distributed builds with agents)
• Multilanguage build support (Batch, Ant, Python, Perl, Shell Script)
• Extensible: + than 150 plugins.
• Community: +than 190 commiters / + than 13000 installations (by now the most popular CI server).

Hudson, best practices

(Chuck Norris hilarious facts are encapsulated in a popular Hudson plugin)

- Single purpose jobs

In order to know clearly what was the point of failure, is better to split long processes in small tasks, taking advantage of the ability of linking jobs. A typical set of task include:

• setting up the environment
• build
• testing
• tagging or saving the last known good state in an staging area

- All assets within the repository (of the SCM)

Hudson has the ability to connect to most of the SCM’s This connection is used to trigger new builds after a commit is made and to view the captured changeset.

- Automated Testing

By including automated testing to our code we will get an accurate impression of the state of the code. The process has to lack of any manual intervention and should be capable of being executed from the command line.

- Stable builds promotion

(SCM tag, branch or file copy)

The end of a successful process is a good opportunity to tag or just copy it as our latest and tested version.

- Chuck Norris is always watching you!

He will, if you install his plugin (#5)

Next steps

After setting up a CI server, is a good idea to start advancing in other related areas like:

• Using Test Driven Development
• A CI server makes it easier to use use tools that measure complimentary aspects of the quality of our code, like the test coverage, level of documentation, unused paths, “crapness” etc. Many of them can be used as a plugin within Hudson.
• Setting up distributed builds, which turns up to be very easy to set up and could let us test our code in different platforms and speed up the process.

References:

1. Martin Fowler on Continuous Integration – http://www.martinfowler.com/articles/continuousIntegration.html
2. About Continuous Integration – http://en.wikipedia.org/wiki/Continuous_Integration
3. Hudson Home – http://hudson-ci.org
4. CI servers matrix - http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
5. Chuck Norris plugin - http://wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin