Jenkins evolution
Typically, most users or organizations will start off on their Jenkins journey by setting up a basic, standard Jenkins installation to manage a few simple development tasks. The most common use is to build your source code, either periodically or whenever it changes in your central repository (Git, Subversion, and so on).
Using Jenkins to automate this type of simple and repetitive task often provides a lot of useful benefits very quickly and easily. Straight out of the box, so to speak, you get a bundle of helpful features, such as task scheduling and job triggering, building and testing report pages, sending out email notifications and alerts when there are new issues, and providing rapid and live feedback of how healthy (or not!) your code base currently is. If you don't already have a tool in place to provide these things, then setting up a standard Jenkins instance will provide these initial basic features, which on their own may well transform your development process.
The next logical step after this is to gradually add a little more intelligence and complexity to the setup—does the code compile ok? How many unit tests have been passed now, how long does the application take to compile? Oh, and could we show on a web page who has changed which parts of the code base? Is our application running faster or better than it was previously, and is it stable? Even before we begin to add any type of extension or customization, the core Jenkins installation provides a plethora of options here—you can choose to build your application on any platform that runs Java (which means pretty much anywhere these days), and you can also do this in whatever way that suits you and your current setup the best, including using the standard and popular build tools such as Ant or Maven, and/or re-using your existing Ant or Maven build scripts, or your Linux Shell or Windows DOS scripts.
You can also easily set up a cross-platform environment by deploying Jenkins Slave Nodes, which will allow you to run different jobs on different hosts. This can be useful in the environments that use a combination of operating systems; for example, your application runs on Linux, and you want to run your browser-based tests using Internet Explorer on a Windows host.
This ability to act as an easily configurable "wrapper" for your existing process, combined with the flexible nature of Jenkins, makes it very easy to adapt your particular setup to suit your requirements with minimal change or interruption. This makes Jenkins far easier to implement than having to change your existing build and deployment processes and practices just to accommodate the requirements of a new tool.
After this stage, the benefits of setting up a Continuous Integration environment often become quite obvious: if we can automatically build our code and package our application so easily, wouldn't it be great if we could go on to deploy it too? And then, if we did that, we could automatically test how our new application performs on a replica of the target platform!
On reaching this point, Jenkins will be a pivotal tool in your Continuous Integration process, and the more you can extend it to suit your growing and specific requirements, the more benefit you will receive from it.
This leads us to extending Jenkins, which is what we will be looking at in the rest of the book.
The simplest way to extend Jenkins is through its fantastic and ever-expanding wealth of plugins. It is always recommended and informative to browse through them; existing plugins are frequently being improved upon and updated with new features, and new plugins are being added to the list all the time. We are going to do more than just review a few popular plugins here though—by the end of this book, you should have the ability to take your usage of Jenkins to the next level to create your own custom plugins and extensions and work with the many features and interfaces that Jenkins provides us with for extension and interaction.
We will be taking a detailed look at the following:
- The different ways in which we can use the existing features
- Interacting with Jenkins through its various interfaces and APIs
- How to interact with Jenkins from within your IDE
- Ways to build upon the existing functionality to suit your needs
- Developing, testing, and building your own custom Jenkins extension
Here are the main tools that we will be using to help us extend Jenkins, along with some information on setting them up, and the sources for further help and information if required:
- Java Development Kit (JDK): You will need a version of this at the same bit level as your Java IDE, that is, both will need to be 32 bit or 64 bit, depending on your architecture and preference. You can choose from IBM, Oracle, or OpenJDK 6.0 or later. Each vendor supplies installation instructions for all major platforms.
- Java IDE: We will mainly be using Eclipse, but will cater to NetBeans and IntelliJ too, where possible.
The most recent versions of each of these IDEs are available at their respective websites:
- Mylyn: This is used to communicate with Jenkins from our IDE. If Mylyn is not already included in your IDE, you can download it from the Eclipse site here: http://www.eclipse.org/mylyn/downloads/. We will cover this in detail in Chapter 3, Jenkins and the IDE.
- Maven: We will be using Maven 3 to build the Jenkins source code and our own custom plugin. Maven is a Java tool, so it will need to know about the JDK of your system.
- Jenkins Source: This will be downloaded by Maven.
- Git: On most Linux platforms, the equivalent of
sudo apt-get install gitshould suffice. On Mac, there are several options, including thegit-osxinstaller on Sourceforge. For Microsoft Windows, there is an executable installer available at http://msysgit.github.io/.
We will go in to more specifics on the installation and usage of each of these components as we use them in the later chapters.
