Friday, August 14, 2009

Agile Best Practice of Continuous Integration (CI)


Setup an integration build environment that triggers every 5 minutes! That type of instruction will send your head spinning pretty fast if you don't see what's exactly involved. The purpose of doing so is for a best practice of Agile Software Development called Continuous Integration. For those practicing Agile, this is a familiar term. If you've done iterative software development before, you'll value the need for a continuous integration.

How in the world are you going to trigger a build every five minutes? The next guy wouldn't get a chance to send in his changes! Well, that's exactly where the strength of CI is. Anything missing from the build will become apparent very quickly and the culprit can be quickly chastised if necessary. =) The idea is to find integration errors and tests failure ASAP before the procession of events get further away and costs more to fix.

Martin Fowler introduced CI as follows: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." (read more here)

The frequent code check-ins and automated build execution helps tightened the feedback cycles to increase software quality. This means not only developer's feedback cycles are increased, it will also increases business users and stake holders satisfaction of the product. Less bugs means less problem at demos and less iritation to the stake holders, which hopefully generates constructive improvement requests.

Back to the crazy 5 minutes automated build frequency, this does not mean the automated build will terminates itself and checkout new codes before it finishes its cycle. Rather the CI mechanism will check if any new changes can be detected in the source/version control system. If there's any new changes then the automated bulid will run until it finished and then wait for the set frequency (in this case 5 min.) and repeats the process. If no changes is detected, then no build is executed.

No comments:

Post a Comment