Chapter 13. Continuous integration
This chapter covers
- The benefits of continuous integration
- Using Jenkins to build a Gradle project
- Exploring cloud-based CI solutions
- Modeling a build pipeline with Jenkins
If you’re working as a member of a software development team, you inevitably will have to interface with code written by your peers. Before working on a change, a developer retrieves a copy of the code from a central source code repository, but the local copy of this code on the developer’s machine can quickly diverge from the version in the repository. While working on the code, other developers may commit changes to existing code or add new artifacts like resource files and dependencies. The longer you wait to commit your source code into the shared code repository, the harder it’ll become to avoid merge conflicts and integration issues.
Continuous integration (CI) is a software development practice where source code is integrated frequently, optimally multiple times a day. With each change, the source code is compiled and tested by an automated build, which leads to significantly less integration headaches and immediate feedback about the health status of your project.
Integrating source code committed to a central VCS by different developers should be a nonevent. Continuous integration is the process of verifying these integrations by building the project in well-defined intervals (for example, every five minutes) or each time a commit is pushed to the VCS. You’re perfectly set up with your Gradle build to make this determination. With every commit, you can compile the code, run various types of tests, and even determine if the code quality for your project improved or degraded. What exactly do you gain? Apart from the initial time investment of setting up and configuring a CI server, continuous integration provides many benefits:
Despite all of these benefits, introducing continuous integration to a team or organization requires an attitude of transparency, and in extreme cases may even require a complete culture shift. The health status of a project is always visible through a dashboard or notifications. This means that a broken build won’t be a secret anymore. To improve project quality, try to foster a culture of intolerance for defects. You’ll see that it pays off in the long run. With these benefits in mind, let’s see how continuous integration plays out in practice by playing through a typical scenario.
Continuous integration is best demonstrated by seeing it in action. All you need is a CI server installed on your local system, access to a central VCS repository, and a project you can build with Gradle. This section assumes that you’ve already installed a Java version on your machine.
Jenkins is the perfect candidate for getting started quickly. Its distribution can be downloaded and started in literally a minute. For your convenience, I uploaded the sample To Do application to GitHub, an online hosting service for projects. GitHub is backed by the free and open source VCS named Git. Don’t be intimidated by this suite of tools if you haven’t used them yet. You’ll install and configure each of them step by step. You’ll start by signing up on GitHub if you don’t yet have an account.
Jenkins (http://jenkins-ci.org/) originated as a project called Hudson (http://hudson-ci.org/). Hudson started out as an open source project in 2004 at Sun Microsystems. Over the years, it became one of the most popular CI servers with a huge market share. When Oracle bought Sun in 2011, the community decided to fork the project on GitHub and call it Jenkins. While Hudson still exists today, most projects switched to using Jenkins because it provides the best support for bug fixes and extensions. Jenkins, which is entirely written in Java, is easy to install and upgrade and provides good scriptability and over 600 plugins. You’re going to install Jenkins on your machine.
Cloud-hosted CI servers deliver immediate benefits. First and foremost, you don’t need to provision your infrastructure and maintain the software. Depending on the purpose of your build, the demand for hardware resources can be high. Continuous integration in the cloud promises to provide a scalability solution when you need it. Need more CPU power to satisfy the demand of multiple, concurrent compilation build jobs? Simply scale up by purchasing a plan that provides more hardware resources. Many cloud-based CI servers directly integrate with your online repository account like GitHub. Log into your account, select a project, and start building. The following list gives an overview of some of the popular CI server solutions in the cloud with Gradle support:
Travis CI: Travis CI (https://travis-ci.org/) is a CI service suitable for open source, small-business, and enterprise projects. The service provides its own homegrown CI product that lets you build projects hosted on GitHub. Projects need to provide a configuration file checked in with the source code to indicate the language and the command you want to execute.
While it may be convenient to run all possible tasks of your Gradle build in a single build job, it’s hard to find the root cause of a failed build. It’s much easier to break up the build process into smaller steps with their own technical responsibility. This leads to clear separation of concerns and faster, more specific feedback. For example, if you create a step for exclusively executing integration tests and that step fails, you know two things. On the one hand, you can be certain that the source code is compilable and the unit tests ran successfully. On the other hand, the root cause for a failed integration test is either an unsuccessful test assertion or a misbehaving integration with other components of the system. In this section, you’ll model the first steps of your build pipeline, as shown in figure 13.20.
A build pipeline defines quality gates between each of the steps. Only if the result of a build step fulfills the requirements of its quality gate will the pipeline then proceed to the next step. What does this mean for your example? In case the suite of integration tests fails to run successfully, the pipeline won’t trigger the next build step that performs code analysis.
In this chapter, you experienced firsthand how easy it is to set up continuous integration for a project. You installed the open source CI server Jenkins on your machine and created a build job for the To Do application. In a first step, you learned how to periodically retrieve the source code from a GitHub repository and trigger a Gradle build. One of Jenkins’s strong suits is reporting. You configured your build job to display the unit test results and code coverage metrics. Hosting a Jenkins instance on a server requires hardware resources and qualified personnel to maintain it. We explored popular, cloud-hosted CI solutions and compared their advantages and disadvantages. While hosting a CI server in the cloud is convenient, it may become costly with an increasing number of build jobs and features.
In the next chapter, you’ll learn how to build the distribution for your project and how to publish it to private and public artifact repositories. In later chapters, you’ll extend this pipeline by creating jobs for publishing the WAR file and deploying it to a target environment.