|
Code-Build-Debug, Revisited
Borland is set to announce the technology preview of a new build management system. But will it play in your development team?
by Peter Varhol
September 20, 2006
In the era when software was developed by individual programmers sitting in front of a PC or terminal, you emphasized the code-build-debug cycle of software development. It was simple, but fundamental. You wrote code, compiled and built (which was in many cases little more than compilation at the time), and then debugged. It was considered poor form to use the compiler to help you debug, but many of you did it anyway.
As software became more complicated, and the build process more convoluted, you used make files and did not look forward to creating and debugging make files so you could build and debug your application. Building became a chore, rather than an automatic process.
Software became more complicated still, and took a significant amount of time to develop. There was a time in the 1990s, for example, when the builds for Windows NT began taking the Microsoft development team longer than 24 hours to create. A few of you persevered, but most let building of software slide to project milestones.
Yet the importance of the build process has grown. If you cannot build your software, then you cannot effectively debug it. Some software development teams still manage nightly builds, by cobbling together an automated process based on multiple tools and handwritten scripts. Most take into consideration the time and effort involved in creating and maintaining this type of build environment, and decide to limit their pain by building only at milestones.
Microsoft has begun addressing the build part of the software development lifecycle through the Visual Studio 2005 Team System (VSTS). VSTS offers a new source code control system (thankfully, not based on SourceSafe), check-in processes, and automated quality tools. Of course, you have to use Microsoft Visual Studio 2005 as the IDE for VSTS.
For those of you who do not use Visual Studio 2005 as your IDE, Borland is announcing its implementation of technology acquired from Gauntlet Systems earlier this year. This product, also called Gauntlet, features the ability to automate large parts of the build process, and to aggregate and display data on builds over time.
"Building is a neglected part of the application lifecycle because it's too difficult," says Rob Cheng, Director of Product Marketing for Borland. "Our goal is to let a development team easily set up and use default build processes. If building can become a natural part of the daily software activities, [then] it will improve software quality."
Building Is an Ongoing Process
Borland defines a process called "continuous builds," where a build occurs every time there is a check-in. The goal is to bring building back to where it belongs in the code-build-debug cycle, rather than holding formal builds until the project milestones.
In the pre-technology preview build of Gauntlet, you set the product up through a Web-based administration page (see Figure 1), a process that takes perhaps 15 or 30 minutes, depending on the size of the project (you might also need to set up paths and other Java development tools). Then you can check out, start coding, and use Gauntlet in the same way you would any configuration and build tool.
In addition to a build environment, Gauntlet also offers testing tools, including a unit test and performance test. When you check in, it completes a build, but the build is equivalent to a local build to ensure that your check-in doesn't break anything. Only after the build passes smoke tests is it considered the most current build.
Strengths of Gauntlet
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, or where any failures might have occurred. But Gauntlet tracks closely the build development history. This provides a deep view of build problems that might otherwise go undetected.
For example, you can look at paths to determine where builds fail most often. Instead of having the offending developers buy multiple iterations of build-break donuts, you can pinpoint where breaks or performance issues occur most often. As apposed to the responsibility of a careless developer, a build break might represent an area that is not well specified or understood by the team. Gauntlet offers you the level of detail necessary for making these types of determinations.
Gauntlet provides build process information in a Web dashboard that displays charts of build results, tests, and developers. You can drill down on the Web page to more detailed data, or export to Excel and perform your own analysis and charting. There are multiple tabs on the page, so that you can easily switch from analysis to the various types of administration that are available.
Gauntlet's IDE and Platform Support
In theory, Gauntlet supports building with any IDE on any platform. However, its initial release has tools and processes that work primarily with Java development. It is also written in Java, and incorporates several open source components, such as the Apache Web server, Tomcat Servlet engine, and Postgres database. Most impressively, Gauntlet installs and runs easily (albeit slowly in the technology preview form); it is more designed as server-based software.
Building software does not 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 development history is lost. And if you cannot learn from history, then you are doomed to repeat it.
About the Author
Peter Varhol is Editor-in-Chief of FTPOnline.
Back to top
|