What is Jenkins?
Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:
- Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
- Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.
Who is using it?
A lot of companies and organizations. Most instances tend to run inside the firewall, but Google can tell you publicly visible instances. We also have some statistics collected from the anonymous usage survey here
Jenkins offers the following features:
- Easy installation: Just java -jar jenkins.war, or deploy it in a servlet container. No additional install, no database.
- Easy configuration: Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There's no need to tweak XML manually anymore, although if you'd like to do so, you can do that, too.
- Change set support: Jenkins can generate a list of changes made into the build from Subversion/CVS. This is also done in a fairly efficient fashion, to reduce the load on the repository.
- Permanent links: Jenkins gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
- RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
- After-the-fact tagging: Builds can be tagged long after builds are completed.
- JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
- Distributed builds: Jenkins can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks.
- File fingerprinting: Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Jenkins, and is ideal for projects to track dependency.
- Plugin Support: Jenkins can be extended via 3rd party plugins. You can write plugins to make Jenkins support tools/processes that your team uses.
Jenkins Best Practices
Continuous Integration with automated test execution has seen broad adoption in recent years. The ideas behind Continuous Integration have changed how companies look at Build Management, Release Management, Deployment Automation, and Test Orchestration. This section provides a set of best practices for Jenkins - A Continuous Integration Solution to provide executives, business managers, software developers and architects a better sense of the development progress and code quality of projects throughout the development lifecycle. (View Jenkins Best Practices)
Note that many links below refer to Hudson, the original name of Jenkins.
- http://linsolas.developpez.com/articles/hudson/ (French)
- Kohsuke presenting Hudson in FOSDEM 2008 (video)
- Introduction to Hudson (French)
- Introduction and best practice by Kohsuke (Japanese)
- Introdución a Hudson (Spanish)
- Kohsuke presenting Hudson in JavaZone 2009 (video)
- Hawebs.net docs for Hudson (简体中文 Simplified Chinese)
- Hudson Wiki - Hudson 中文维基 (简体中文 Simplified Chinese)
- Continuous Integration in my Butt with Hudson JavaOne 2009 presentation by Kohsuke (English)
- Doing More With Hudson JavaOne 2010 presentation by Kohsuke
- Hudson presentation at San Francisco JUG by Kohsuke (English, video and slides)
- Continuous integration with Jenkins CI (Czech)
- DZone ref card for Jenkins (English)
You can launch Jenkins with Java Web Start if you want to give it a test drive. Once it launches, visit http://localhost:8080/ in your browser to get to the dashboard. Any configuration that you do with this Jenkins instance will be stored in
~/.jenkins, so your data will survive a Jenkins process restart.
To run Jenkins, you need the Java Runtime Environment (JRE) 1.7 or later. After you download jenkins.war, you can launch it by executing java -jar jenkins.war. This is basically the same set up as the test drive, except that the output will go to console, not to a window.
Alternatively, if you have a servlet container that supports Servlet 2.4/JSP 2.0 or later, such as Glassfish, Tomcat 5, JBoss, Jetty 6, etc., then you can deploy jenkins.war as you would any WAR file. See this document for more about container-specific installation instruction.
Once the war file is exploded, run chmod 755 jenkins in the exploded jenkins/WEB-INF directory so that you can execute this shell script.
If you're running on Windows you might want to run Jenkins as a service so it starts up automatically without requiring a user to log in. The easiest way to achieve this is to simply download and install Jenkins via the native Windows installer, which can be found on the Jenkins main page. Just download the .zip file, unpack it, and click through the install wizard. The wizard both installs Jenkins and sets up the Jenkins Windows service for you.
Another way to run Jenkins as a service is to first install Tomcat as a service and then deploy Jenkins to it in the usual way. Another way is to use the Java Service Wrapper. However, there may be problems using the service wrapper, because the Main class in Jenkins in the default namespace conflicts with the service wrapper main class. Deploying inside a service container (Tomcat, Jetty, etc.) is probably more straightforward, even for developers without experience with such containers.
Also, see how other people are deploying Jenkins to get some idea of how to make it fit your environment.
- Case study of Sven Reimers
- Case study of Kohsuke Kawaguchi
- Case study of Rhett Sutphin
- Case study of Ned Collyer
- Case Study of Arnaud Lacour
- Case Study of JBoss
- Using Hudson with Tibco BusinessWorks
- Case Study of Xuggler and Red5
- Case Study of ADempiere
- we'd love to list yours here. Please talk to us.
Jenkins is distributed under the MIT License.