View source for The Road to the Final Four

''by [[Yvonne Nonte Stoetzel]] and [[Gregg Mason]]''

Well, the post season of professional football has come and gone, but college basketball is just going into shutdown mode for you sports fans out there in developer land. In "[[Going the Extra Yard]]" in Volume 5 of ''The Developer Connection News'', we discussed diskette and CD-ROM creation processes as part of the regular season play. The natural progression of post-season play for a build and integration team is product installation, build verification test (BVT), source code propagation, and postmortem analysis. These "Final Four" elements round out the build and integration process. In this article, we will address the basic concepts and debugging techniques for product installation, BVT, source code propagation, and postmortem analysis So settle back and enjoy the game as we switch "channels" for a post-season discussion of public build and integration.

==Tip Off - Installation==
Installation of a newly built product can be a tip-off to the build's initial quality. Product installation can exercise key functions or aspects of the program or application. Additionally, a successfully installed system/application presents itself to further testing procedures. So, the clock is set and the game begins.

==The Starting Lineup==
For best results, use "starting lineup" hardware. In other words, install the target operating system and/or application on a cleanly formatted hard disk partition. This ensures that preexisting files (or hard disk damage) that might be on the system from previous installations will not alter the results of the installation test. Once the product installation is successful, try your second string hardware. It's recommended that the installation process also be executed on a dirty system (a system that contains previously installed files). The primary justification for this is customer usability, because customers usually will not format their systems prior to installing a new application.

==Executing the Game Plan==
All supported media types should be tested for installation errors (for example, 3.5" diskettes, 5.25" diskettes, CD-ROM, and LAN). Oftentimes, individual media types support different machine environments. Each supported hardware configuration should be installed with the appropriate media. An inconsistency or error in one media type can cause the whole product to fail Installation problems can point out media layout problems or executable inconsistencies such as file checking, unpacking problems, time and date validation (service), corrupted files, and damaged media.

==Eliminating the Technical Foul==
The purpose of BVT (Build Verification Test) is to identify any build-related problems prior to running the installed product through a full test cycle. Therefore, it's best if this test is short (say 20 minutes or less) BVT should exercise basic functions of the product, such as opening and closing OS/2 sessions, invoking the main program, creating and deleting files, visually spot-checking colors and screen output, and so on. Automation of test scenarios by using command files or REXX scripts can ensure quality, consistency, and timely execution of BVT. When writing these test cases, it's a good idea to include function in the programs to log the test results. Then the results can be quickly scanned for failures/errors.

==Knowing When to Call a Time-Out==
If the installed product passes this quick BVT, it is a fair indicator that the build will withstand further, more stringent testing. Unfortunately, things don't always go as smoothly as planned. If you're like us, there will come a time when things ''fall all over the floor'' and you're left there to pick up the pieces. Just as in the game, there is a point when you need to take a few minutes and gather your thoughts before launching a full attack. A quick scan of any obvious blunders can keep you from being embarrassed. Things like double-checking build error logs or viewing the ''CONFIG.SYS'' file for corruption or incorrect statements can easily identify basic installation problems.

==Altering the Game Plan==
Once you've determined that nothing is obviously wrong, it's time to break out the debugging tools and techniques. Therefore, it's a real time saver to have a few good debugging tools at your fingertips. You can find the OS/2 Kernel Debugger, symbols files, and other debugging information on Volume 7 of The Developer Connection for OS/2 CD-ROM. It's usually a good idea to have any debugging modules ready and available before testing the installation. This way, crucial debugging time is not wasted trying to create or locate debugging tools. Another time-saver is a dedicated debugging machine (this is a good way to use an older 286 system).

==Publishing the Scores==
Making the source code and output executables of a build available to the development community is known as ''propagation'' or ''publication''. The build is of no value if developers cannot make use of the information it contains. A simple way to make the build available is by syncing (or copying) the contents of the build machine to a development server. A separate dedicated machine is ideal for providing current levels of a build to developers. Some of the pluses to a dedicated development server are:
* Multiple levels of a build (this is especially handy when debugging build and integration problems)
* Reduced development compile time (for example, a one-line change to a C file can be rebuilt, and the remaining untouched OBJ's for that component can be relinked against the last build output)

''Don't forget'': Closing out a driver makes the build and integration process whole. This step is really just the gathering of the levels of files in a given build (for example, 4.23) and recording the data and source code for later use. It enables build reproducibility and ensures, by default, that development is making changes to the latest level of built files.

==Post-Game Evaluation==
The best way to improve build cycle time is to understand the strengths and weaknesses of the process. Recording the process steps in an ongoing build status log can help you evaluate the process. The build log can be set up to automatically or manually record pertinent data. We recommend tracking statistical data in the build log on start/stop times, defect counts and content, owners, support personnel, status information, compile times, machine usage, debugging issues, and communication paths. After each build, this log can be reviewed for possible process/procedure improvements in order to increase productivity and decrease build cycle time. We have found this log to be extremely useful in identifying and eliminating repetitive problems.

==Cutting Down the Net==
Well, the final four elements of the public build and integration process - Installation, BVT, Propagation, and Postmortem Analysis - have been discussed, and the road trip is complete. From "[[Avoiding the Build Lab Blues]]", to "[[Ready! Set! Build!]]", "Going the Extra Yard", and now "The Road to the Final Four", we have provided you with all of the major steps necessary to create a build and integration process capable of taking your team to the championship.

{{IBM-Reprint}}
[[Category:Developer Connection News Volume 7]]