Continuous Integration

I l @ ve RuBoard

The following sections describe how XP continuous integration fosters teamwork on a Web development project.

Checking in Work

Everyone on our team is encouraged to check in their work often, at least once, and preferably many times, a day. All work, from code to graphics to content, is added to the repository. Once a new piece of work is checked in, we have a script that compiles any object code and then deploys to a development directory on the Web server, where another script runs all the automated tests we have written. The results of this build are published to a Web page.

Before we had this automated procedure, a team member would call out that she had checked in and the designated builder, often the project manager, would do the build manually. The automated system is more efficient, but sometimes we miss the sound of people calling out. It gave the shop an atmosphere of accomplishment.

Keeping on Track

Continuous integration protects the project from going too far off track. That is why, when the build breaks, we fix it immediately. What breaks a Web build? In addition to the unit tests we run a link checker, a spell checker, a code checker, and a page- size measuring tool.

A build fails if

• A unit test fails

• A spelling error occurs

• A missing page is found in the site

• A link is broken

• The parsed XML is not valid HTML

• The page is larger than an agreed on size

Any of these things can require someone to go back and fix his work. In Web XP, builds give feedback to the whole team and make everyone's work better.

I l @ ve RuBoard