My Introduction to Continuous Integration

As my software engineering class moves on to the second half of our semester, we have begun focusing on working in groups to efficiently build a new program, the WattDepot Command Line Interface. The details of this project will be discussed in a future blog post over the next few days, but here I wanted to address the idea of Continuous Integration, which is a tool that we are using to facilitate our teamwork.

Continuous integration is a software development practice where team members integrate their work frequently, to decrease the time required for integration at the end of a project. This usually involves team members updating at least once a day, if not more often, leading to numerous integrations by the team each day. In addition, each integration is verified by an automated build that detects errors and notifies the developers of these errors as soon as possible.

For my class, we are using Hudson as the tool to facilitate continuous integration. During the Hudson setup, you can set it to poll for SVN updates with a specific frequency, and build the project each time there is an update. My project is hosted within Google Code, so I have Hudson check the site every five minutes to see if there is an update. Additionally, Hudson is set up to e-mail the relevant Google Group when there is a failed build; ideally, Hudson would also e-mail the developer that broke the build, but the functionality was not working when we tested in last Wednesday.

In class, I tested Hudson by building the project manually, committing a small change and ensuring Hudson noticed the change and built the job, as well as breaking the build and seeing if the appropriate e-mail was sent. Overall, I feel that Hudson was a little tedious to set up and that this would have been very confusing if not for my teacher's walkthrough of the process. However, since this is a one-time time cost for the project, it was worth it. Even though I tried to run the ant verify before committing my changes through SVN, a few minor errors still slipped through the cracks (for instance, making all changes for Checkstyle and forgetting to run verify again, which would have caught my error in not updating references to a method I had renamed).

Although I have not yet completed my project, I can already see the advantages of Continuous Integration, because it makes it easier to catch issues quickly. Also, Continuous Integration encourages me to always keep the project in a working state, because I don't want Hudson to have my project flagged as having a failed build for long periods of time. Other than the setup time involved (which was maybe about 30 minutes to ensure everything was working properly and was just a bit confusing), I see no immediate disadvantages to using Hudson. I'll continue to use this tool throughout the semester and will be refining my observations about it.