Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Why we are moving to Jenkins

1 min read

When it comes to testing I want to keep moving forward, and recently that has involved moving to Jenkins. This is why we are moving our testing suite from Hudson to Jenkins. Hudson has been able to provide us with everything we needed to handle our tests. So why are we moving?

Why move from Hudson?

Hudson and Jenkins both came from the same codebase that diverged in 2011. The split has two different sides to the story. Each side feels the other is the fork of the code base and they are working on the original codebase. I’m not going to touch that bag of snakes. The important part is that the project split and it seems that the majority of the developers and plugin creators followed Jenkins. Just 2 years later Jenkins was seeing more active development than Hudson. Now Hudson isn’t being maintained and was announced as obsolete in February 2018. Hudson has reached end of life whilst Jenkins is continuing to grow.

What can Jenkins offer over Hudson?

Even ignoring the EOL of Hudson, since the split, Jenkins has seen a large amount of the original community and plugin developers follow them instead of Hudson. The plugin support for Jenkins is much better than Hudson. There is a more diverse selection of plugins available allowing us to expand functionality by moving to Jenkins.

Jenkins and Hudson also provides us with a remote access api. This api can be used to give us another way to interact with our tests. Using the REST api gives you another way to interact with Jenkins without using the build in UI. However moving to Jenkins gives us more ways to use this api.

However Jenkins isn’t perfect. There are still things I prefer in Hudson. I prefer the UI for the job configuration in Hudson than in Jenkins. I feel it looks cleaner and it is smaller, allowing me to see more without having to scroll.

Hudson also allows for multiple git repositories per job out of the box. However to do the same thing in Jenkins required me to download a plugin to get the same behaviour. Whilst this isn’t a major problem as the plugin exists it would have been nice to have the functionality built in.


We have kept our Hudson machine active for quite some time but our circumstances are changing and our test suite is growing. Now we are considering how we want the tests to grow we have decided to move over to Jenkins. The flexible and easily expandable nature of Jenkins makes it easier to for us to grow the tests as needed. And as you can see above the only real arguments I can make for Hudson over Jenkins are cosmetic. For me function has to overrule aesthetics.

Do you prefer Hudson or Jenkins? Let us know in the comments.

Can we help you to solve any of these problems?

IDRsolutions has been helping companies to solve these problems since 1999.

Convert PDF to HTML5 or SVG with BuildVuConvert PDF to HTML5 or SVGConvert AcroForms and XFA to HTML5 with FormVuConvert PDF forms to HTML5
Java Image SDK for working with Image files with JDeliJava SDK for Image files JPedal Java PDF SDK for working with PDF filesJava SDK for PDF files
Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Leave a Reply

Your email address will not be published. Required fields are marked *

IDRsolutions Ltd 2021. All rights reserved.