First Looks

Gauntlet: Dive Deeply Into the Build Process

Keep track of build histories with this robust ALM tool that provides continuous integration and code coverage for agile software development.

• By Peter Varhol
• 06/01/2007

Building software is the last great frontier of software development. Yes, there are well-defined best practices that include nightly or even continuous builds, repeatable build processes, and continuous integration and testing. But few development teams employ all of these practices. In fact, a discouraging number of teams build only at major milestones, keeping their collective fingers crossed that code and libraries of the correct versions are in the right place. Any problems at this stage can take days or even weeks to track down.

Borland hopes to address this frontier with Gauntlet, a build management and analysis tool for Windows and Java development. You set it up through a Web-based administration page, a process that takes 15-30 minutes, depending on the size of the project. Then you can check out the project, start coding, and use Gauntlet as a way to keep track of files that are part of the build.

In addition to a build environment, Gauntlet also offers testing tools, including unit test and performance test. When you check in your code, Gauntlet performs a build, but that build is the equivalent of a local build, to ensure that the check-in doesn't break anything. Only after that build passes the smoke tests is it considered to be the most current build.

Perhaps the true strength of Gauntlet is in its analysis and presentation of data. It provides fundamental information on the build process, such as the success of the build and accompanying smoke tests, or where any failures might have occurred. Gauntlet keeps close track of a project's history, which gives you an exceptionally deep view of build problems that might otherwise go undetected (Figure 1). For example, you can look at paths to determine precisely where builds are failing most often. Rather than having the offending developers buy multiple iterations of build-break donuts, you can pinpoint where breaks or performance issues occur most often. Gauntlet provides the level of detail that you need to make such determinations.

Gauntlet conveys this information in a Web dashboard that displays charts of build results, tests, and developers. You can drill down on the Web page to get more detailed data, or export to Excel and perform your own analysis and charting. There are multiple tabs on the page, so you can easily switch from analysis to the various types of administration tools that are available.

In theory, Gauntlet supports building with any IDE on any platform. However, it is written in Java, and incorporates several open source components, including the Apache Web server, Tomcat Servlet engine, and Postgres database. It does have a plug-in architecture so you can add the third-party tools of your preference. Most impressively, Borland has tuned the install process to be almost automatic, with few installation or configuration hassles.

Gauntlet's recommended system requirements include a hefty 2.0 GHz dual-core processor and 2 GB of memory, along with disk space requirements that vary significantly based on the number and frequency of builds. It runs on XP, Windows 2003 Server, or Red Hat Linux 4. I ran it with close to the recommended configuration, and performance was adequate, although the creation and display of Web pages didn't happen as fast as it would with a rich-client interface.

Gauntlet debuts in a market that is becoming rapidly crowded, with IBM BuildForge, Openmake Meister, several Electric Cloud products, and Codefast PerfectBuild. And, of course, there is the 800-pound gorilla: Microsoft Team System. All do slightly different things, but all address software builds in some way. Gauntlet should have a role in this crowd, with its focus on testing and rapidly pinpointing build problems. Building software doesn't get much respect in software development organizations. Everyone expects it to just work, and people tend to get frustrated when it does not. However, perhaps the biggest disadvantage of ad hoc build processes is that history is lost. And if we cannot learn from history, we are doomed to repeat it.

Gauntlet
Borland
Web: www.borland.com
Phone: 408-863-2800
Price: Contact vendor for pricing
Quick Facts: Keep track of build histories with this robust ALM tool that provides continuous integration and code coverage for agile software development.
Pros: Provides highly detailed information about your builds.
Cons: Java-based app required a JDK (Java 5 or later); large resource requirements.