What's the workflow of Continuous Integration With Hudson?

6
votes

I am referred to Hudson today.

I have heard about continuous integration before, but I have no idea what the heck is a ci-server.

Hudson is really easy to install in Ubuntu and in several minutes I managed to set up an instance of it.

But I don't quite understand the workflow of a ci-server, or how am I supposed to use it?

Please tell me if you have experience about ci, thanks in advance.

Edit:

I am currently using Mercurial as my SCM, and I wonder what is the right way to use it with Hudson.

I have installed the Mercurial Plugin of Hudson, and I create a new job with a local repository. When I commit in the repository the Hudson job is built with the latest version of my source code.

If what I used is a remote repository, what's the workflow like?

Is it something like the following?

  1. Set up a Hudson job with the repository
  2. Developer makes a local clone of the repository
  3. Developer commit and push changes
  4. The remote repository update with the incoming changeset
  5. Run a Hudson build

There may be something I misunderstanded at all, please help me point it out.

2
continuous-integrationhudson
Related: stackoverflow.com/questions/616149/… – Yuval Adam
Please post your edit as separate question as it's clearly another question. Maybe add a link to this one for the context, but create a new question. Thanks. – Pascal Thivent
Thanks for your suggestion, Pascal. – satoru

2 Answers

8
votes

Continuous Integration is the process of "integrating software" continuously i.e. as frequently as possible (ultimately after each set of changes) to avoid any big-bang integration and all subsequent problems by getting immediate feedback.

To implement Continuous Integration, you first need to automate the build of your software (where build means of course compiling sources, packaging them, but also compiling tests, running the tests, running quality checks, etc, anything that will help to get feedback on the health of your code). Then you need to trigger the build on the latest version of the sources on a particular event (a change in the repository, a temporal event), to generate reports and to send notifications upon failure (by mail, twitter, etc).

And this is precisely the responsibility of a CI engine: offering trigger mechanisms, being able to get the latest version of the sources, running the build, generating and publishing reports, sending notifications. CI engines do implement this.

And because running a build is CPU and Disk intensive, CI engines usually run on a dedicated machine (or even a farm of machines if you want to build lots of projects).

Back to your question now. Once you've got Hudson running, configure it (Manage Hudson > Configure System): setup the JDK, build tools, etc. Then setup an Hudson Job and follow the steps: configure the location of the source repository, the build tool, the trigger, a notification channel and you're done (you can do more complex things but that's a start).

For more details on the setup, check:

7
votes

Martin Fowler's overview of continuous integration is one of the canonical references. In my opinion, using automation to make sure your code base is healthy is one of the most useful things that you can set up.

Update Sorry that I didn't have much time earlier to expand on my reply. @Pascal_Thivent is right that in order to effectively use CI, you need to be able to automate your builds, tests, etc. CI is actually a good forcing function for this. For me, it's one of those little warning flags if I start to think that it would be too painful to put a build into Hudson. It means that something is not quite right.

What I like about Hudson is that it's flexible enough to accommodate different workflows. We use it for both builds / unit tests and releases. And it eliminates a lot of the worry about certain release procedures only working in one person's environment.

What I don't like about Hudson is that it is occasionally unstable when new builds break plugins. I've had a couple of upgrades (2 out of 10 or so) go bad because of incompatibilities. I do two things now:

  1. I never upgrade my team's Hudson server to the latest and greatest right away. I generally only upgrade when there are significant new features, or bug fixes.
  2. I now have a basic Hudson instance set up with all my plugins on a virtual machine with some dummy builds that I fire up to test out any new upgrades before doing it on the public server.