So far, we have been depending on the developer to ensure that the changes they push to the GitHub remote repository do not cause regressions elsewhere in the application. However, this is not always a fully reliable means of determining the quality of the code, as the main code base will likely have moved on due to other developers also pushing their changes. When integrated together, they might cause tests or even code to fail to compile.

Continuous integration monitors changes to the source control repository and automatically starts its own build on the fully integrated source code base. Failures are reported back to the developers who last pushed code to the repository.

In this part of the chapter, we are going to explore this process using the popular Jenkins Continuous Integration server, which uses a script that is also stored in source control to perform the build and test steps. Before we get into setting this up, let's take a moment to review the Continuous Integration (CI) process that we are going to use.