Continuous integration (CI) is a software engineering practice that aims to minimize software development time while applying rigorous quality control from the beginning and at every step of the process. If you're ready to jump on the CI bandwagon, turn to Jenkins CI.
The need for faster and better software development methods is nothing new. What's changed lately is the fact that it's almost impossible to stay competitive if you don't use the best new tools. Factors such as globalization, outsourcing, and crowdsourcing have increased the time pressure on software development teams, while adding to the likelihood that team members cannot meet regularly to debug and test their code.
Continuous integration helps development teams face these challenges. The name of the method describes the process it facilitates: code, integrate, compile, and run all possible tests in small steps, but from day one and as frequently as possible, in order to detect and eliminate all bugs as soon as they're born. CI works only if all those steps are completely automatic and as transparent as possible for all the developers involved; that's where Jenkins comes in.
Jenkins, or any CI framework, begins helping when a developer gets some code to the point where he thinks it works. He then commits it to Jenkins and moves on to work on the next task. Jenkins, noticing the code commit, starts a build and test execution on one of its machines. If and when something fails, Jenkins notifies the responsible developer about the problem. How quickly this happens depends on the complexity of the project, but it's often within 10 minutes to an hour. This quick feedback cycle is one of the great benefit of Jenkins: the developer learns that some change was wrong while he still has the whole context fresh in his mind.
Kohsuke Kawaguchi, one of the main developers of Jenkins and the founder of Hudson, the CI server from which Jenkins was forked, says all software companies should implement a tool like Jenkins. "It frees up developers from doing things machines can do, so developers can working on more fun stuff, and it increases productivity. It collects information from the problems and regressions so that developers can just act on them. It also increases the transparency of the software development, making it easier for people related to the project, such as managers, developers of the other components who depend on it, QA people, operations people, and so on, to get insights on the project without bothering the developers, and without causing any additional overhead. Improved transparency also means improved predictability.
"CI is really the only game in town that allows developers to effectively take advantages of the abundance of computing power that defines this decade in our industry. As computing gets cheaper, we software engineers need to make use of a larger number of computers to do our job and strive for more productivity. Jenkins really helps you do that."
According to Kawaguchi, what has to be present in order for a developers team to start using Jenkins successfully is someone eager to try out something new and push the envelope of automation.
Organizations can start using Jenkins either with a bottom-up or top-down approach. The first scenario is what happens when one guy on the team wants to improve his work, and starts running Jenkins for his project. Pretty soon the rest of the team finds out about the benefits, and from there adoption spreads gradually.
"At the smallest extreme," Kawaguchi says, "a single-person project benefits from CI because it frees up the developer from waiting for the test execution to complete. We have a lot of individual freelance folks using Jenkins."
In other places Jenkins had been adopted in a top-down approach. "Managers like what Jenkins brings on the table, so they allocate a team to deploy it. A lot of features in Jenkins make it usable in a large environment. Jenkins helps capture the knowledge of how to build and how to run tests in a server, making it easier for a developer to move on or come back to a project later. Bigger projects also benefit from the additional transparency and the automation brought by Jenkins. We have a number of deployments that use more than 100 machines under one single Jenkins installation."
However, Kawaguchi says too few organizations take advantage of Jenkins' distributed build capabilities. "I still see a lot of people not using multiple computers for CI. To me that's very wrong. This part of Jenkins is well proven. We worked hard to make doing this easier. If you are not doing it, you definitely should."
Kawaguchi also recommends users take advantage of the software's support of build promotions. A promoted build is a successful build that has passed additional criteria, such as more comprehensive tests. When a build is promoted, you can have Jenkins perform special actions automatically, such as email notifications or copying the build somewhere for tests that cannot be done automatically. "A lot of people start with automated builds and tests, and that's good, but once you got those pieces of automation in place, you can then move on to coordinate those pieces to create a larger, more autonomous automation workflow. Build promotion really helps that."
For a relatively young project, Jenkins has had a colorful history. Kawaguchi started the Hudson project when he was a Sun employee. When Oracle bought Sun, it acquired ownership of the code and of the Hudson trademark. Kawaguchi and the other project members began having disagreements with the new owners about the hosting infrastructure, which quickly grew into questions about the control of the Hudson project. Eventually, failing to reach agreement with Oracle, the project team forked the code, changed the name to Jenkins, moved the development infrastructure to its own GitHub repository, and started producing Jenkins releases that built on the original Hudson code base.
"The divorce period, as I call it, was stressful," Kawaguchi says. "We had to talk about a lot of non-technical things. But once that was over and Jenkins was born, we began making a lot of progress. I've published a slideshow to show this progress in perspective.
"Recently, an announcement from Oracle about moving the Hudson project to the Eclipse foundation caused an additional stir. We had rounds of conversations in the Jenkins community meetings, but now the community is feeling like just moving on, minding our own business. It's hard to put two projects back together, and no one is willing to spend time making that happen."
Kawaguchi says a new stable release line is due soon, aimed at organizations that don't necessarily want the latest features and bug fixes, but prefer slower release cycles with more stability. He says the new stable release is better tested from some of the project's large-scale users, such as Red Hat and Yahoo.
Allowed tags: <a> link, <b> bold, <i> italics