The OpenALM Family
Borland has restructured its existing portfolio of tools and solutions around the OpenALM strategy. According to Borland's Mike Hulme, the company's OpenALM objective to support any platform-agnostic software development process or tool in a measurable way stemmed from what Borland calls its "Five Rights of OpenALM Manifesto." These are:
- Customers have the right to manage their process.
- Customers have the right to maintain independence from the vendor's agenda.
- Customers have the right to choose their development methodology process.
- Customers have the right to learn from and utilize industry best practices.
- Customers have the right to receive the best value.
Running the Gauntlet
The first Borland toolset that fully encapsulates these principles is an automatic, server-side continuous build tool appropriately named "Gauntlet" (www.borland.com/us/products/silk/gauntlet). In addition to almost instant application builds and results reporting upon code check-in, Gauntlet can integrate with three types of version control systems (CVS, Subversion, and Borland's own StarTeam) and several automated test suites including Mercury TestDirector and Borland's SilkCentral Test Manager (www.borland.com/us/products/ silk/silkcentral_test).
Gauntlet itself is a Java-based application running within its own Tomcat web server. Accessing its functions is done entirely through a standard web browser such as Microsoft Internet Explorer or Mozilla Firefox. The intuitive user interface provides one- or two-click access to a majority of the program's features and settings. Dashboard-style graphs abound throughout most nonAdministrative pages, emphasizing the helpful and numerous metrics collected from Gauntlet's build processing.
Establishing a new project with Gauntlet is simple. Enter the location with proper authentication credentials of a CVS, Subversion, or Borland's own StarTeam code repository. Going a step further, Gauntlet features an impressive historical project view generator called "Replay," which identifies every code check-in made with that project before Gauntlet was employed to manage the build process, performing builds and, if configured, tests on each of these check-in points. Once Replay has been employed, its results can be used like a time machine to study the trends of a project's code history. This can be useful not only for projects currently in progress (to help estimate time and potential issues as that project continues), but also for identifying past project potholes and help developers and managers either avoid or at least plan accordingly for similar project types in the future.
Another technically exciting feature Gauntlet delivers is its ability to sandbox each developer's check-in build to protect it from the main trunk in the event of a problem. Developers who have previously invested in source code and build-management efforts have no doubt encountered errant check-ins that not only broke the main build but also consumed desperately unavailable cycles of time trying to identify and isolate the problem area.
