Increased Regression Efficiency with Jenkins Continuous Integration Before You Finish Your Morning Coffee

The topic of Continuous Integration (CI) is one which has started to become more and more common in the world of verification. For those unfamiliar with CI, it is a concept often associated with Agile programming practices, and it runs off the basic principle that the longer a branch of code is checked out, the more it begins to drift away from what is stored in the repository. The more the two diverge, the more complicated it becomes to eventually merge in changes easily. Ultimately leading to what is commonly referred to as "integration hell". To avoid this, and ultimately save engineers time, CI calls for integrating regularly and often (typically daily).

Regular check-ins are of course, only half the equation, you need to be able to verify their changes quickly as well, otherwise many small check ins over several days, is no different than one large check in at weeks end. Commonly, in a Continuous Integration environment, a CI server monitors the source control for check in's, which in turn triggers a CI process (time-based triggers are also common). This process will then build the necessary design files and run the requisite integration tests. Once complete, the results of the tests are reported back to the user, and assuming everything passed, can now be safely committed to the repository.

^{Figure 1: Continuous Integration Flow}

By following this model, issues can be caught earlier in the development process, and can be resolved quicker as there is less variance between check ins. There are several options to choose from when it comes to CI, however, far and away the most common solution today is Jenkins. So, what is Jenkins, and why is it the favorite CI tool of so many users?

Meet Jenkins

Jenkins was originally created by Kohsuke Kawaguchi while he was working for Sun Microsystems back in 2004. At the time, however, the project was called Hudson. It was not until several years later in 2010, after Oracle had acquired Sun, issues began to arise between the community working on Hudson, and Oracle. At that time, a vote was taken as to whether development would continue, or if the community would break ties with Oracle, and fork the project. After an overwhelming vote, the project was forked, and Jenkins was born. A majority of those working on and using Hudson at the time, eventually migrated over to Jenkins. Today there are over 130k active installations of Jenkins
worldwide.¹

ZeroTurnaround is a development company, which amongst other things, conducts an annual global survey of Java developers, and produces a report of the tools and technologies most commonly used by the industry. Just recently, the released their 2016 survey results² which polled over 2000 respondents on various topics, one of which was their use of CI. Of those respondents, 60% were stated to be using Jenkins, the second place tool was Bamboo, used by only 9% of the respondents. Oh, and remember Hudson, it came in at only 3%.

Jenkins has wide appeal to many developers. Firstly, it is open-source and freely available. With an incredibly active and dedicated community, issues are resolved very quickly, and members are eager to help. As a tool, it is easy to install, and highly configurable for any environment via, all through its convenient web interface. While Jenkins itself has a lot to offer, one of its biggest benefits is that it is so highly extensible via plugins to the tool. At present, it boasts nearly 1400 plugins from close to 600 contributors. If there is something Jenkins does not do natively, chances are, there is a plugin to enable that functionality.

To get start to get a feel for all that Jenkins has to offer, you really need to try and use the tool. After all, I said it is easy to setup, and I think you will agree once you try it for yourself.