Continous Integration is a software engineering term describing a process that completely rebuilds and tests an application frequently. Cruise control is one of the more popular ones. it is written in java, and boasts tight integration with java tools like Ant. Buildbot by Brian Warner is a continuous integration server built from Python and Twisted.
Funnily, although Buildbot is a mature CI server with unique advanced features, it does not often get mentioned in traditional XP/Agile circles. E.g, this feature matrix at the Damage Control website merely leaves a question mark on most entries for Buildbot. This is likely to be because a lot of the momentum in XP community has been on "Enterprise" application development projects that tend to use Java and C#, so continuous integration servers written in those languages have been more prominent. In this respect, Damage Control itself is another interesting CI server - it is written in Ruby, so is probably worth another post on this blog (Dynamic languages rule!).
Despite the current lack of awareness about BuildBot, nevertheless it is quite popular in the FOSS world. As this google search shows, a lot of FOSS projects use it to continuously integrate their source code. A key distinguishing feature of BuildBot is that is designed from scratch to be a distributed build tool.
Buildbot consists of a single
This means is that Buildbot can be configured to simultanously perform different builds on completely different machine configurations in response to commits in the source code repository or at user request. This feature makes BuildBot uniquely useful in multi-platform build scenarios.
Another nice feature that I've not seen on other CI servers: BuildBot learns how long each build takes - so that when new builds are triggered, it lets you know how long there is to go before the build completes.
If these are not enough to whet the appetite, BuildBot has a feature that allows developers to see what would happen with if they checked in their source trees prior to commiting them. What use is that? If full pre-commit builds take a long time on single developer machine, as is often the case if one has extensive unit/functional test suites or needs to test these on multiple deployment configurations, they can be delegated to a cluster of build slaves!
Find out more from http://buildbot.sourceforge.net
Funnily, although Buildbot is a mature CI server with unique advanced features, it does not often get mentioned in traditional XP/Agile circles. E.g, this feature matrix at the Damage Control website merely leaves a question mark on most entries for Buildbot. This is likely to be because a lot of the momentum in XP community has been on "Enterprise" application development projects that tend to use Java and C#, so continuous integration servers written in those languages have been more prominent. In this respect, Damage Control itself is another interesting CI server - it is written in Ruby, so is probably worth another post on this blog (Dynamic languages rule!).
Despite the current lack of awareness about BuildBot, nevertheless it is quite popular in the FOSS world. As this google search shows, a lot of FOSS projects use it to continuously integrate their source code. A key distinguishing feature of BuildBot is that is designed from scratch to be a distributed build tool.
Buildbot consists of a single
buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what and when to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results.This means is that Buildbot can be configured to simultanously perform different builds on completely different machine configurations in response to commits in the source code repository or at user request. This feature makes BuildBot uniquely useful in multi-platform build scenarios.
Another nice feature that I've not seen on other CI servers: BuildBot learns how long each build takes - so that when new builds are triggered, it lets you know how long there is to go before the build completes.
If these are not enough to whet the appetite, BuildBot has a feature that allows developers to see what would happen with if they checked in their source trees prior to commiting them. What use is that? If full pre-commit builds take a long time on single developer machine, as is often the case if one has extensive unit/functional test suites or needs to test these on multiple deployment configurations, they can be delegated to a cluster of build slaves!
Find out more from http://buildbot.sourceforge.net
No comments:
Post a Comment