Jenkins (http://jenkins-ci.org) is a firm favorite in the CI world and is the basis for some cloud services (for example, cloudbees; https://www.cloudbees.com). It is very widely used and no section about continuous integration would be complete without mentioning it.

We are going to need a basic install of Jenkins on our local machine to work through this section. Let's follow these steps:

1. If you have already installed an application server such as Tomcat for the previous section, you'll just need to download the WAR file and drop it into the webapps directory of your application server. If you decide to go the Docker route, you can run the following command (you will need to create the ~/jenkins directory on your local machine):

docker run -it --name jenkins-instance  
    -p 8080:8080  
    -p 50000:50000  
    -v ~/jenkins:/var/jenkins_home  
    Jenkins 

2. To get to your Jenkins instance, navigate to the following URL in your browser:

http://localhost:8080 

3. The first thing that you will see is a screen asking you to unlock Jenkins:

4. Have a look in your Terminal window (assuming you are using Docker) and you will see something that looks like this:

5. Copy the password from the Terminal, enter it, and then click on Continue. You will then be asked which plugins you would like to install. Just use the default Jenkins recommendations for now. Jenkins will then download the required plugins and set itself up ready for initial use. The final setup step is to create yourself an admin account (you can use username admin and password admin again; this is another temporary account).

6. Now that Jenkins is ready to go, you will see the Welcome to Jenkins screen:

Let's have a look at how we can set up a build in Jenkins that will enable us to run our tests:

1. The first thing to do is to click on the create new jobs link:

2. Put in the name of your build and then select the Freestyle project option.
3. Next, click on OK and you will be taken to the build configuration screen. Click on the tab that says Source Code Management, and select Git and fill in your details:

4. Next, we can set up our build triggers and our build environment. It's normally a good idea to have a Git hook set up to trigger builds every time a change is committed to source control:

5. Then, we need to set up our Maven job. Click on the Add build step button and then select Invoke top-level Maven targets. Refer to the following screenshot:

6. Now you just need to enter your default Maven goal, and we are ready to go. Refer to the following screenshot:

7. Click on Save and you will be sent to your newly created project; that's all! Refer to the following screenshot: 

You should now be able to run your Jenkins build and it will download all the dependencies and run everything for you.

So far, we have looked at how we can set up a very simple continuous integration service, but this is only the tip of the iceberg. We have used continuous integration to give us a fast feedback loop so that we are notified of, and can react to, problems quickly. What if we could extend this to tell us not just whether there are any problems, but whether something is ready to be deployed into production instead? This is the goal of continuous delivery. Refer to the following diagram:

What's next after continuous delivery? How about continuous deployment? This is where we get to the point that we are so confident in our pipeline that as soon as every continuous delivery phase has been marked as passed, the code will automatically be deployed to live. Just imagine a new feature being completed and within a matter of hours we have performed enough testing on that functionality that we can automatically release it to live.

From code complete to being in the hand of your customers on the same day! Refer to the following diagram:

We haven't got quite that far yet. We now have a basic CI setup that we can use to run our tests on CI, but we still have some pretty big gaps. The basic CI setup that you have so far is running on one operating system and cannot run our tests against all browser/operating system combinations. We can deal with this issue by setting up various build agents that connect to our CI server and run different versions of operating systems/browsers. This does however take time to configure and can be quite fiddly. You could also extend the capabilities of your CI server by setting up a Selenium-Grid that your CI server can connect to and run various Selenium test jobs. This can be very powerful, but it also does have setup costs. This is where third-party services such as SauceLabs (https://saucelabs.com) can be used. Most third-party grid services have free tiers, which can be very useful when you are getting started and working out what works for you. Remember that getting set up with the one third-party service does not lock you into them. One Selenium-Grid is pretty much the same as another, so even though you start off using a third-party service, there is nothing to stop you building up your own grid, or configuring your own build agents and moving away from the third-party service in the future.