Buildbot (http://buildbot.net/) is software written in Python that automates the compile and test cycles for any kind of software projects. It is configurable in a way that every change made on a source code repository generates some builds and launches some tests, and then provides some feedback:
This tool is used, for instance, by CPython core, and can be found at http://buildbot.python.org/all/waterfall?&category=3.x.stable.
The default Buildbot's representation of build results is a Waterfall view, as shown in the preceding diagram. Each column corresponds to a build composed of steps and is associated with some buildĀ slaves. The whole system is driven by the build master as follows:
- The build master centralizes and drives everything
- A build is a sequence of steps used to build an application and run tests over it
- A step is an atomic command that does the following:
- Checks out the files of a project
- Builds the application
- Runs tests
A build slave is a machine that is in charge of running a build. It can be located anywhere as long as it can reach the build master. Thanks to this architecture, Buildbot scales very well. All of the heavy lifting is done on build slaves, and you can have as many of them as you want.
Its very simple and clear design makes Buildbot very flexible. Each build step is just a single command. Buildbot is written in Python, but it is completely language agnostic. So, the build step can be absolutely anything. The process exit code is used to decide if the step ended as a success, and all standard output of the step command is captured by default. Most of the testing tools and compilers follow good design practices, and they indicate failures with proper exit codes and return readable error and warning messages on theĀ stdout or stderr output streams. If that's not true, you can usually easily wrap them with simple Bash script. In most cases, this is a simple task. Thanks to this, a lot of projects can be integrated with Buildbot with only minimal effort.
The next advantage of Buildbot is that it supports the following version control systems out of the box, without the need to install any additional plugins:
- CVS
- Subversion
- Perforce
- Bzr
- Darcs
- Git
- Mercurial
- Monotone
The main disadvantage of Buildbot is its lack of higher-level presentation tools for presenting build results. For instance, other projects such as Jenkins can take the notion of unit tests being run during the build. If you feed them with the test results data presented in the proper format (usually XML), they can present all the tests in readable form, like tables and graphs. Buildbot does not have such a built-in feature, and this is the price it pays for its flexibility and simplicity. If you need some extra bells and whistles, you need to build them by yourself or search for some custom extensions. On the other hand, thanks to such simplicity, it is easier to reason about Buildbot's behavior and to maintain it. So, there is always a trade-off.
Let's take a look at Travis CI in the next section.