When you exit from the command prompt or shell that started the process that we looked at previously, the Jenkins instance will stop with the exit, so for anything beyond a very quick ad hoc test, some form of initialization or process management script is highly recommended. Such a script can also be easily tailored to perform a few "nice to have" functions for you, for example, things such as these:

This Ubuntu-based example script from the home page demonstrates many of the previously mentioned features of Jenkins that is running under Tomcat. The script can be found at https://wiki.jenkins-ci.org/display/JENKINS/JenkinsLinuxStartupScript and is as follows:

#!/bin/sh
#
# Startup script for the Jenkins Continuous Integration server
# (via Jakarta Tomcat Java Servlets and JSP server)
#
# chkconfig: - 85 15
# description: Jakarta Tomcat Java Servlets and JSP server
# processname: jenkins
# pidfile: /home/jenkins/jenkins-tomcat.pid

# Set Tomcat environment.
JENKINS_USER=jenkins
LOCKFILE=/var/lock/jenkins
export PATH=/usr/local/bin:$PATH
export HOME=/home/jenkins
export JAVA_HOME=/usr/lib/jvm/java-6-sun
export JENKINS_BASEDIR=/home/jenkins
export TOMCAT_HOME=$JENKINS_BASEDIR/apache-tomcat-6.0.18
export CATALINA_PID=$JENKINS_BASEDIR/jenkins-tomcat.pid
export CATALINA_OPTS="-DJENKINS_HOME=$JENKINS_BASEDIR/jenkins-home -Xmx512m -Djava.awt.headless=true"

# Source function library.
. /etc/rc.d/init.d/functions

[ -f $TOMCAT_HOME/bin/catalina.sh ] || exit 0

export PATH=$PATH:/usr/bin:/usr/local/bin

# See how we were called.
case "$1" in
  start)
        # Start daemon.
        echo -n "Starting Tomcat: "
        su -p -s /bin/sh $JENKINS_USER -c "$TOMCAT_HOME/bin/catalina.sh start"
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch $LOCKFILE
        ;;
  stop)
        # Stop daemons.
        echo -n "Shutting down Tomcat: "
        su -p -s /bin/sh $JENKINS_USER -c "$TOMCAT_HOME/bin/catalina.sh stop"
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f $LOCKFILE
        ;;
  restart)
        $0 stop
        $0 start
        ;;
  condrestart)
       [ -e $LOCKFILE ] && $0 restart
       ;;
  status)
        status -p $CATALINA_PID -l $(basename $LOCKFILE) jenkins
        ;;
  *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
esac
exit 0

Note that the http://jenkins-ci.org/ home page also hosts Native Installers for many popular operating systems under the Native packages column. These pages provide download links and installation instructions for each OS.

You may want to look at running Jenkins in a J2EE container too, which can often lead to a more seamless fit with your existing software stack and architecture. This may mean that you will inherit additional benefits, such as the container's logging, authentication, authorization, or resilience. Jenkins can be run with many popular J2EE compatible containers, including the following:

There are more init script examples and detailed installation instructions readily available on the Web, which should cover any combination of operating system and container setup. The point of this is that you should be able to set up Jenkins to suit your environment and preferences.

For the purposes of this book, we will assume that Jenkins is being run directly from the command line on the local host. If you are using a J2EE container to host the application or running the application on a remote host, the only difference you will notice is that you may need to perform additional admin and deployment steps.

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:

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:

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.

Before we conclude this chapter, here is a list of the key practices of Continuous Integration (as defined by Martin Fowler in 2006) with the examples of the ways in which Jenkins can be used to help you achieve them:

The benefits that can be realized once you have achieved the preceding best practices are often many and significant—your team will release software of higher quality and will do this more quickly and for less cost than before. However, setting up an automated build, test, and deployment pipeline will never be enough in itself; the tests, environment, and culture must be of sufficient quality too, and having the developers, managers, and business owners "buy in" to the processes and practices often makes all the difference.

In this preparatory chapter, we have taken a look at the basics of Jenkins; how it is used from both functional and practical points of view. We have run through a high-level overview of the toolset that we will be using to extend Jenkins in the following chapters and reviewed the best practices for Continuous Integration along with the ways in which Jenkins can be used to help your team achieve them.

In the next chapter, we will take a look at the ways in which we can extend the Jenkins user interface to make it more productive and intelligent, and how we can extend the user experience to make life easier and more productive for end users, as well as for Jenkins admins, build scripts, and processes.