Continuous Integration Build Scenario

Charlie, a build master, has been tasked with setting up a Continuous Integration build for his project so that all the developer and project stakeholders will be able to get a better picture of the real-time progress on the project.

Ideally, every time there is a new change committed, AnthillPro would build the project using the latest sources and then run an automated suite of unit tests. If all the tests pass, then the build should be marked as a success, otherwise, it should be marked as a failure.

Quiet Period

A Continuous Integration build should be run often, ideally every commit would result in a Continuous Integration build. But that's often not possible or realistic or even desirable in the real world. For example, lets say that to fix an issue the developer had to modify two source files. He first commits one of the files forgetting for the moment about the other one. A few seconds later he realizes that the other file needs to be committed as well. This will result in two commits. Ideally, there should be a Continuous Integration build that captures both these commits. If there were a build between the two commits then such a build would fail.

To ensure that such a situation will result in a single Continuous Integration build, we can use a Quiet Period. The Quiet Period is a length of time that the source code repository must be without any commits before a Continuous Integration build can proceed. Ideally, this length of time will be long enough for the developer to make all commits that are part of the same change to the source code and short enough to still get quick feedback on commits. Chalie sets his at one minute. The purpose of the Quiet Period is to make sure that the source code taken for a Continuous Integration build contains a consistent set of changes. AnthillPro fully supports a configurable Quiet Period duration.

Repository Triggers and Scheduled Triggers

There are two ways to implement a scheduling system for Continuous Integration builds. The first and most advantageous is for the Build Management Server (BMS) to receive an event from the SCM every time there is a commit. The BMS will have to make sure that the Quiet Period passes without commits and then it may start a build of the project. If the project were currently being built, then the BMS may wait until the current build completes before starting a new build. AnthillPro fully supports this mechanism of using repository triggers to signal commits. The only limitation on this technique is that not all SCMs support repository triggers, and thus for those systems there is another means of scheduling Continuous Integration builds.

The second way to schedule Continuous Integration builds is to get a log of changes from the SCM. Typically there is a schedule configured to run every few minutes. Every time the schedule ticks, it checks for changes in the SCM since the previous build. If there are changes then a Continuous Integration build is required and the BMS must make sure that it waits for the Quiet Period. The Quiet Period starts from the time of the last commit in the change log. If the Quiet Period will not end until sometime in the future, then the BMS must get another log of changes once the Quiet Period completes -- this log need only include changes since the time of the previous change log and the time of the expiration of the Quiet Period. If there are no new commits, then the Quiet Period has been met and a build may proceed. If there are changes, then the BMS must again wait for the Quiet Period since the time of the last commit -- this cycle will continue until the Quiet Period has been satisfied.

AnthillPro supports both mechanisms for scheduling Continuous Integration builds and is thus ideally suited as a Continuous Integration server. Coupled with other features such as distributed and multi-platform builds, as well as the BuildLife concept and the ALA features, AnthillPro is a Continuous Integration server in a class of its own.

Thanks to AnthillPro, Charlie can rest assured that his Continuous Integration system builds what and when it is supposed to and the results are a real reflection of his team's efforts.