Hudson is a continuous integration server for Java development.
The development of this platform started with Hudson while Jenkins was forked from Hudson when Sun was acquired by Oracle who aimed to develop a commercial version of the software. Since the fork, Jenkins has grown to be much more than a continuous integration solution
They both run inside servelet containers on Java application servers allowing for easy integration into your existing workflow.
Our top four reasons for using Hudson and Jenkins:
At IDRsolutions, Hudson and Jenkins are a key part of our Java development process. We make use of both servers and are gradually moving across all our instances to Jenkins. Here are some of the reason make use of these platforms. For simplicity, we’ll refer to both as Jenkins.
1. Continuous Integration
At its core, Jenkins is a continuous integration server. Continuous integration is a development approach that implements a “develop > test > deploy” loop meaning any changes to the software are automatically tested before deployment. Furthermore, upon test failure, the changes will not be pushed onto the main platform. As a result, developers can make changes without worrying about breaking main builds.
Jenkins support Maven, Gradle and Ant to suit your build needs. At IDRsolutions, we use Maven and ensure our test process is efficiently implemented. Firstly static analysis via PMD, FindBugs and CheckStyle for finding quick bugs, followed by our JUnit test suite for each module and finally producing Javadocs.
2. Scheduling
Continuous integration is not just for executing tasks based on user interaction. Your projects may implement time-sensitive tasks or cron jobs. On Jenkins, you can create jobs and schedule them to run at certain times of day or in intervals. As such, we execute performance tests once a day, testing across different Java versions, roll-out daily builds and so on.
3. Open-source code and extensibility
Jenkins is the leading open-source automation server with over 1400 plugins for development automation. With a strong community, the project is ever-evolving with new features, plugins and an active mailing list. You and others can identify your pain points and either find a plugin to suit, be able to make a suggestion on the mailing list, or dive right in and develop your own.
4. Customisation and scripting
Every team is different and has different requirements for their workflow. There might be occasions where there is no plugin to suit that one task you wish you could avoid. To solve this, key part of any automation is scripting.
In addition to the plugins, Jenkins supports various scripting languages allowing for the execution of tasks specific to your needs. Creating python scripts to automate repetitive tasks on your workstation is great. Using scripts as part of continuous integration is even better.
Furthermore, if you feel that task is more universal, consider creating a plugin to meet your needs and help others with similar pain points.
Summary
We use Jenkins to enforce continuous integration and unit testing to improve our Java development. The automation server comes with many features and is constantly improving. Due to this, it is extremely extensible, customisable and able to automate any server-based tasks from even a single instance.
Lastly, do you use Hudson and/or Jenkins? What are your favourite plugins or features? Let us know by either leaving a comment below or contacting us directly.
Are you a Developer working with PDF files?
Our developers guide contains a large number of technical posts to help you understand the PDF file Format.
Do you need to solve any of these problems?
| Display PDF documents in a Web app |
| Use PDF Forms in a web browser |
| Convert PDF Documents to an image |
| Work with PDF Documents in Java |
Hi Ovidijus,
the topic implies, that you explain, why your company uses both tools – Jenkins and Hudson – at the same time. I was looking for the reason, why you chose to take that path. Reading further on, I discovered the line “We make use of both servers and are gradually moving across all our instances to Jenkins.”
Reading on, I was hoping, that you put emphasis on your decision, but then the following sentence removed the hope I had left: “For simplicity, we’ll refer to both as Jenkins.”
After reading the whole article, the topic is a bit misleading. You explain, why you use a CI-tool like Jenkins or Hudson. It could be either of them. After doing some market research, I found out, that Hudson has dwindled into meaningless, after Oracle tried to change it into an enterprise product when accquiring Sun Microsystems. This spawned the fork Jenkins, as we know it today. Once again proof, that it is difficult to make a buck out of originally free and open source tools. Once the community has started off and gotten used to the “free” taste, say goodbye to any enterprise revenue idears. You can also tell the power of the open source community by looking at those examples. This does not necessarily have to be a bad thing, it just means you have to adjust your profit making strategies.
Regards,
Daniel
Hi Daniel,
Thanks for the feedback!
In terms of why we use both, it’s simply due to to the fact that we started with Hudson. We tried out Jenkins on a separate machine and found it to be superior so made a conscious effort to slowly move over to Jenkins for all our CI. However, the process of moving to Jenkins is not simple considering how far Jenkins has diverged from the original meaning it is not a simple copy/paste task. When you have many tests running on this, essentially legacy, tool the process can take some time but we’re happy to say we’re almost there. As stated in the article, we are moving across to Jenkins as it “has grown to be much more than a continuous integration solution” and as you stated it is under active development and continues to grow in meaningful ways. Apologies if the blending of both into just “Jenkins” within the article made things unclear, it was more so aimed at specifying that Jenkins is the one we’re moving to and the one we should talk about. I completely agree with your point that locking a once-free tool behind a paywall will never bode well with users and the development of Jenkins displays exactly that.
Kind Regards,
Ovidijus