Continuous Integration: Jenkins

What is Jenkins?

Jenkins is the backbone of a Continuous Integration (CI) ecosystem. It allows you to manage your projects and configure how they are built. It can be used with any type of build tools, but it really shines for Maven projects because of the extra functionality it offers. There are robust 3rd party plugins that allow you to do pretty much anything you’d want to do with your build.

In this post, we’re going to focus on installing Jenkins and creating a basic job for the addrbook project we built in an earlier post. In future posts we’ll leverage the Jenkins plugins for more advanced functionality. This post assumes you already have a web app container (eg, Tomcat) and git installed.

Installing Jenkins

1. Download the Jenkins WAR here: https://jenkins.io/
2. Deploy the WAR to your app server.
3. Open http://localhost:8080/jenkins/ in your browser
4. Jenkins will do some automatic configuration and then display the home page. This is where you would see a list of jobs, but we haven’t create one yet.
5. Next, let’s install the git plugin:
6. Click on ‘Manage Jenkins’ in the left nav
7. Select ‘Manage Plugins’
8. Click the ‘Available’ tab
9. Type ‘git plugin’ in the filter (upper right of screen) and click the checkbox next to ‘Git Plugin’ plugin.
10. Click the ‘Install without resart’ button.
11. Wait for the installation to complete.
12. Next, let’s configure the Maven plugin
13. Click on ‘Manage Jenkins’ in the left nav
14. Click on ‘Configure System’
15. Scroll down to the ‘Maven installations’ section and click the ‘Add Maven’ button
16. Provide the name ‘Maven 3’ and select the desired version of Maven (latest version recommended).
17. Click the ‘Save’ (bottom of the page)
18. You’ll be redirected you to the Dashboard, which displays all your jobs. This screen is currently empty because we haven’t created a job yet.

Creating a job

1. To create a job, click on ‘New Item’ in the left nav
2. Provide the name ‘addrbook’, select ‘Maven project’ and click OK
3. Now you’ll be at the configuration screen with a slew of options. We’ll be using the default options except for the following:Source Code Management:
   1. Select ‘Git’ with url:

   https://github.com/thoward333/addrbook.git
   Build Triggers:

   1. Select ‘Poll SCM’ and provide a cron for every 5 minutes:

   H/5 * * * *

4. Click ‘Save’ (bottom of the page)
5. Click ‘Build Now’ in the left nav to trigger a build
6. You’ll notice a progress bar for ‘#1’ appeared in the left nav to indicate that the job is currently building
7. To view the console output in real-time, click on the build and select ‘Console Output in left nav’ (shortcut: Next to the ‘#1’ there is a drop down menu where you can link directly to the ‘Console Output’)
8. You can download the WAR by clicking on the build and accessing the ‘Module Builds’ section (bottom of page)

Exploring the goodies

You might be thinking, “Why did I go through all that just to build a WAR?”. There are many goodies we just gained access to, but haven’t yet leveraged, such as build history and email notifications. An implicit benefit of using Jenkins is that it is guaranteed to be a “clean” build. For example, sometimes developers forget to run unit tests–or skip (the horror!)–but Jenkins never forgets. Sometimes developers forget to check in all source files, which breaks the build. Since we configured Jenkins to poll SCM (see Creating a job, step #5), the error will be discovered sooner and with more detail. The job can be configured to send email notifications on build failures (or every build) and the email notification will contain a list of commits that were introduced in the last build. This allows the team to quickly identify the breaking change (aka donut violation). Jenkins will mark the build as failed if any unit tests fail.

Another benefit is build history, which retains both artifacts and console output. By default, Jenkins keeps these forever, but you can configure the job to discard builds after a certain amount of time and/or to only keep a certain number of builds. An individual build can be labeled specially and/or marked to keep forever. For example, let’s say we want to release build #1 to prod. We can edit the build info to display custom metadata in the build history to clearly identify it as our production release.

Additionally, we have laid the ground work for additional features that we’ll cover in future posts. The final goal will be to have Jenkins be a cradle-to-grave build system, where a developer checks in code and Jenkins will compile, test, analyze (eg, SonarQube), and deploy the application.