Vendor-Supported Solution

There are a few open source projects available that offer continuous integration features, arguable the best known of which are CruiseControl and CruiseControl.NET. Obviously open source projects do not have associated licensing fees, and therefore appear to have a cost advantage over commercial solutions. These solutions are not "free" however. Open source projects often do not come with a wizard-driven setup program and have a high learning curve associated with setting them up. Open source projects also tend to have inadequate documentation, and almost never offer telephone-based technical support. With BuildBeat and Timpani Software, we are here to help your project be successful. We offer a commercial-grade installation program, full documentation, training, telephone-based technical support, and professional services.


 Easiest to Setup

In the course of researching the continuous integration market and developing BuildBeat, we looked at the current offerings in the market place, both commercial and open source. A common thread among many of the solutions we looked at was difficulty in setting them up. Many of the tools we looked at required you to manually edit an XML-based configuration file to configure the tool. In order to edit the XML configuration file, you have to read through the documentation and learn each of the XML tags that are necessary for the configuration process.

With BuildBeat, addressing this deficiency was a high-priority. Not only do we include a commercial-grade installation program, but we also included a configuration wizard that walks you through each step of the process. In addition, the visual BuildBeat Administration tool makes it easy to visually configure your projects, source code control integration points, and build tasks. Each screen is context-sensitive and displays the necessary information you need to enter. You don't need to dig through the documentation to figure out what XML tags you need to use for each task.


 Integrated Data Warehouse

Many continuous integration tools on the market use a combination of an XML-based configuration file, combined with either text-based or XML-based logging output. Early on in the development of BuildBeat, we decided to embrace a relational database architecture instead of using text files for configuration input and logging output. There were several reasons for this.

First, we felt that a complete continuous integration solution was inherently relational. Each project can be associated with multiple builds. Each build can have multiple tasks. Each unit test assembly can have multiple unit test cases. We felt a relational database architecture was the best way to capture and store all of the related information that came out of a continuous integration process.

Second, we felt that it was best to store all of the information associated with a continuous integration process in a single, professional-managed repository. If you are relying on text-based logging output, you have to invent your own processes for managing the myriad of files that result from the continuous integration process.

Third, we realized we could leverage all of the inherent advantages of a relational database system to produce first-class continuous integration reports. Use of data warehousing and online analytical processing techniques become feasible once the relevant information is stored in a relational database.


 Live Build Monitoring via Asynchronous Messaging

Other continuous integration tools we looked at were based on remote-procedure call (RPC) communication from the server to the client, using technologies such as .NET Remoting. The problem with RPC communication is that it is synchronous and therefore prone to performance problems. The client must initiate a connection to the server, and then wait for the server to reply.

With BuildBeat, we wanted to provide advanced features such as live build monitoring of builds in progress. There are times where your build process may take longer than normal to complete, or even "hang" altogether. For example, if you have a time-sensitive or thread-sensitve unit test case, a deadlocking bug could hang the build process. Without an ability to monitor live builds in progress, you would need to wait until the build timeout period elapsed before being notified. Live build monitoring saves you time, and lets you know what is happening on the build server at all times.


 Integrated Support for Unit Testing

Continuous integration and unit testing are inherently joined at the hip. Therfore, it makes sense for your unit testing tasks within your build process to be treated specially. By building awareness of unit testing tasks into the build task list, we can provide extra levels of logging, notification, and error handling. With BuildBeat, all unit test cases are automatically logged into the integrated data warehouse, without you having to do any extra work. Once logged, unit test results can be easily viewed via the web reporting module. Without integrated support for unit testing, you have to invent your own systems and processes for capturing and storing unit test results. Doing this yourself would require writing more complex build scripts. Integrated unit testing support saves time, gives higher-quality log reports, and is easier to maintain.