The IT industry loves a good "Holy War". One of the latest has been the highly visible and at times down right nasty forking of the Hudson Continuous Integration server into the Jenkins Continuous Integration Server. More recently Oracle has announced an intention to release Hudson to the Eclipse Foundation, raising some interesting questions about whether all of this could have been avoided in the first place.

With the situation changing so rapidly, how does a development team, or company make the right choice? After following the evolution of both of these servers, I can safely say that it doesn't matter.

Taking a Step Back from the Fray

Very often as I start a new engagement with a client I find that continuous integration is not one of the tools in their development / integration toolset. These projects often suffer from automated test suites which no longer work, and difficulty reliably deploying the application from environment to environment. To put it simply they lack visibility and repeatability. This often leads to production defects, and at times, very costly production rollbacks.

Continuous integration processes force repeatability through scripted automation, and visibility through test execution and trend reporting. This is the core value of implementing continuous integration. Every time I've setup continuous integration for a client, they wonder how they ever did without it.

When setting up a project for continuous integration you will find that the vast majority of the time and effort goes in to designing the automation approach (Ant, Maven, Gradle, etc), and the metrics the team wishes to measure, as opposed to the actual configuration of that project in the continuous integration server.

So which one is better?

At the heart of every continuous integration server are two basic features: Triggering Automation, and Reporting the Results. All of the test and metric execution is controlled by the decisions you make when you define and build your automation scripts. Your decision on which continuous integration server to use should be based on the following criteria:

  1. Is it fast and easy to setup/maintain with low operational overhead?
  2. Does it support my version control system?
  3. Can it execute and consume the output of my build script?
  4. Does it provide report aggregation for my chosen testing frameworks/metrics?

Both Jenkins and Hudson have their individual strengths and weaknesses, but the great news is that both are fantastic at all of the really important things that a continuous integration server should be.

They are both fast and easy to setup, and switching from one to the other is a fairly simple procedure. So pick your favorite, use it, and if it doesn't fully meet your needs, switch over to the other in less than a day! It's really that easy.

The Bottom Line... Why it just doesn't matter

Any good continuous integration solution provides the basics of triggering and reporting. The real value of continuous integration isn't in the server that executes it, but in the data that comes out of it. The ability to see trends in code metrics, unit and integration tests, and to download the freshest build products as the team works on the project far exceed any minor differences between two really great continuous integration servers. The server itself is the least important feature of any continuous integration solution.

The cost of missing out on the opportunity to improve visibility and repeatability within your project far exceeds making the "wrong" decision in choosing a continuous integration server. With two great choices like Hudson and Jenkins, it's hard to go wrong. Just do it!


Martin Fowler on Continuous Integration:

Hudson Continuous Integration Server:

Jenkins Continuous Integration Server: