Yes! It is I, returned to you after my long slumber, and I have something to tell you about: Jenkins. I recently started a new project and took it as an opportunity to try out the Jenkins CI system. I was not disappointed.
A Little History
Once upon a time, Sun – with the help of the Java community – released a little graphic CI server called Hudson. Their humble project grew to rival the likes of established Java CI systems, like CruiseControl until in 2008 when it became the king of the mountain (or at least won a few prestigious awards). However, the project’s idyllic life was about to be shattered. In 2010, Oracle acquired Sun and, like a newly-widowed evil stepmother, immediately started ruining many of the technologies we loved. Two of the most egregious examples were Hudson and MySql. (And how can we forget about Java? While the most recent version includes a number of small but important features, it’s still insecure). However, the communities responsible for these projects disagreed with Oracle’s desire to take these projects into the cold, forbidding wasteland of corporate management, forked their own repos (Jenkins and MariaDB respectively), and set sail for the bright, balmy paradise of free (libre+gratis) software.
Now that you understand why Jenkins is better than Hudson (which also includes the high ratio of commits to Jenkins : commits to Hudson), we can actually talk about this amazing CI server. It includes many of the features you would expect of a modern CI system: the ability to interface with a large number of version control systems, configurable builds on a project basis, distributed builder nodes, and security through either LDAP or onboard authentication. There are two features that set Jenkins apart in my eyes: a comprehensive configuration UI for both the server and build projects, and a large library of plugins for a variety of applications.
These features are important to me. If you’ve used buildbot or CruiseControl, you know the pain of configuration files (or you’ve become so numb to it you’ve forgotten or you have a much higher pain threshold than I). Here is a mere sample of the options available to you in the main configuration page: environment configuration, VCS settings, build system settings (maven, ant, etc), and email notification settings. Certain plugin settings are also available from this page, like FogBugz and MSBuild settings. I can even say that I almost enjoyed the configuration, and it only took a couple of hours one afternoon to get running from installation to build testing (on a Windows box).
Build configuration is also easy. Most of the options are controlled by check boxes or radio buttons that present relevant details when checked. The VCS sections contain all of the options you would want for determining what to poll/build, but only a few provide authentication options. Overcame this by using configuration files for the account running the service (_netrc, known_hosts, _ssh), though I encountered a problem where this stopped working for apparently no reason. On the other hand, I found build actions and post-build actions easily configured. Decide on the type of action, enter your script or configuration options, then drag and drop the steps to order them. Default build actions include windows and shell scripts (for your shell of choice), ant, and maven. There is also an MSBuild plugin for those of you using Microsoft technologies. While available post-build steps include the usual emails, tests, and downstream builds, also available by default are artifact archiving, publishing, and doc creation. My only complaint here is that the only test framework included by default is JUnit, though both runners and result publishers are available for many other technologies, including MSTest.
One last pleasant surprise I found: if you use SCM Manager, a free source control library, there is a hook plugin for it to start builds whenever a new version is pushed. Score!
In the end, if you need a new CI system (or even if you don’t), you should at least give Jenkins a shake. The easy installation and configuration means that even if you don’t like it, you won’t be out much time, and provided you do like it — oh the things you can do!
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at email@example.com. You can also connect with us on Twitter, Facebook, or LinkedIn.