Setting Up a Continuous Integration Build

An easily reproducible build and testing system allows your development team to focus on coding rather than some complex and error-prone build tool based on a specific local environment. Using a build container such as Maven also reduces the amount of tedious work involved in setting up everyone's local build environment. When you're working in a team, developers will commit code to the SCM only after they have verified that their changes are appropriately tested and that their local build passes. In reality, there are several reasons why a local build would pass on your machine but fail on another developer's: you could have forgotten to update your working copy before committing, you could be using a different database instance, etc. What you'd like to do is find out as quickly as possible if the code that everyone commits is working. A bug introduced by one developer may be an obstacle to another developer's progress, and ideally, you want to build and test a system after each commit so that you can identify problems as they occur. This is known as Continuous Integration.[2]

How do I do that?

The best solution found so far is to set up what is called a Continuous Integration build. You're going to do that now using Maven and CruiseControl (http://cruisecontrol.sourceforge.net/). You're going to set up a continuous build for the Quote of the Day (QOTD) web application introduced in Chapter 3.

The architecture is simple (see Figure 5-3

Get Maven: A Developer's Notebook now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.