View source for Going the Extra Yard

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

Previous issues of The Developer Connection News described some of the elements that are required to produce quality builds. Getting a successful product to the marketplace in software development can be compared to an NFL football team winning the SuperBowl. It takes total team effort in the development community to make their product win in the marketplace. The team has to have the right coach, great players, and winning strategies. Additionally, every member of the team must all work towards the same the objective. This article gives you more players for your winning team -- integration, virus detection, and diskette and CD-ROM creation.

Because products are not always developed as one continuum, you must intermix source code or binaries to make a completely built product. This is best done using a release tree, which gives the development community a clear view of all the product files. A release tree works in much the same way as a coach's pre-game pep talk -- it is a mechanism by which to focus the team. This is an essential step before you hit the field before the big game, or, in our case, before files become an installable product. The release tree concept is based on the idea of copying all of the files that are to be part of the product deliverable from their respective source and output trees to a central location. This has two advantages: ease of maintenance and ease of virus detection. 

==Deciding on the Right Play==

In football, more than one play will gain scoring yardage. This also is the case with populating the release tree. Deciding which method will suit your needs depends on your game conditions. (For example, rain, heat, snow, artificial turf,. . . single or multiple build environments, static or dynamic diskette layouts, and so on.)

You can populate the release tree using either a list file or a component makefile.

The list file can be compared to the run play; that is, it takes a little more work than the pass play. A list file creates a natural breaking point in the process by which errors can be evaluated before they are introduced into a release tree. The primary disadvantage of using a list file is that it must be manually maintained. This can introduce a variety of fumbles such as:

* Files on layout without code to install 
* Files in list file not being shipped 
* Potential for file overlay of duplicate named files 
* Typographical errors

#BLDDR    = source drive designation

#NETINSDR = target drive designationSource files Installed System BLDDR\app\src\component\file1.sym NETINSDR\app\dll\file1.sym BLDDR\app\src\component\file1.dll NETINSDR\app\dll\file1.dll BLDDR\app\src\component\file2.sym NETINSDR\app\dll\file2.sym BLDDR\app\src\component\file2.dll NETINSDR\app\dll\file2.dll

'''Sample Code 1.''' Sample List File

The component makefile, on the other hand, can be compared to the pass play. The pass play is great as long as the receiver is open (the developer has ownership) and the quarterback throws a pass that is on target (the builder detects errors). Makefile manipulation puts the onus on the actual developer to determine which files should be placed in the release tree. It also enables source and output code to be identified easily based on its relative location. The main disadvantage is that if a component fails to build correctly and is not identified through the normal build error detection process, it is possible that a bad binary file will be placed into the release tree.

 #INSTPATH = <specify the path for the files to be put in release tree>
 #Instpath should be defined to get to the root of the install tree.
 #For example, suppose you want to place binaries in
 # \root\rel\app\dll
 # \root\rel would be represented by $(R)
 # Instpath = \app\dll
 # Since REL=$(R)+$(INSTPATH), REL will become
 # \root\rel\app\dll
 $(REL)\your.dll: makefile  $(libpath)\your.lib \
                  your.src your2.src your.def


'''Sample Code 2.''' Sample Makefile

Watch out for the possibility/probability of placing a bad binary into the release tree. Strict enforcement and thorough review of a standard build error detection process is crucial. If this is a high-risk exposure on the part of your process, consider using a list file. Remember with the implementation of the makefile process, binary files are copied into the release tree on the fly. A release tree or list file will work well with either a stand alone or multiple build environment. Usually, game methodology is determined by the coach, or in our case, the lead builder. Whichever method you choose, we recommend that the directory structure mirror the installed system. 

==Scoring a Field Goal==

Virus detection is like scoring a field goal. Although it is not considered critical to the integration process, it could be the difference between winning or losing the game. Without taking the opportunity to get the extra points during the game, it could cost you dearly in the end. From the developer's desk machine, through the public build process, to source code distribution, and external vendors, virus detection is everyone's responsibility. If you are sending or receiving binaries, scan these binaries before introducing them into a public build environment.

IBM uses a variety virus detection techniques. One highly recommended method is nightly time-executed virus detection scripts. This process isolates viruses within a 24-hour period. Bringing the right equipment to the game (such as helmet and pads) can simplify life for everyone on the team by increasing productivity and reducing injuries. This also is true of virus detection tools. A product, such as IBM's AV/2, identifies well-known viruses such as Jerusalem and Friday the 13th. Another nice feature of AV/2 is that it can be command-line driven. This can be especially useful for script-file implementation. For example, if you use a list file to update your release tree, virus detection can be incorporated into part of the release tree population process. This also can be done using the makefile process as a separate step. A demo of Central Point's AntiVirus for OS/2 is available on Volume 5 of the Developer Connection for OS/2 CD-ROM. Another tool, Virus-Net/Pro by Safetynet, Inc., provides virus protection, as well as disaster recovery for OS/2, DOS, and Windows networks. 

==Touchdown!==

As any football fan will tell you, successful touchdowns take more than luck. They take careful assessment, planning, organization, and implementation of knowledge. Based on these elements, a coaching staff will develop a game plan. Diskette creation can be approached in much the same way. For diskette creation to become a reality, quality inputs must be provided For example: what data goes on which diskettes?, are they packed?, is bundling required?

You can obtain this information in two ways: a static list file or dynamically generated list files. If your product rarely changes in content or size, a static list file might suit your needs. However, if your product is complex and ever changing, dynamically generated lists are probably your best solution. Regardless of which productivity tools you implore, building a diskette content list is the first step. PKWare Inc.'s PKZIP and PKUNZIP tools have the option of reading in an input list. These tools create bundled, zipped files on any media type.

Diskette images can be created through different methods, such as Loaddsk and Savedskf in the Productivity Tools section of the Developer Connection for OS/2, Volume 5. SaveDskf creates a softcopy image of a physical diskette. LoadDskf restores the diskette image back to a hardcopy diskette. These tools are great for distributing diskettes over LAN servers, CD-ROMs, or mainframes. If you not only want to create diskette images, but generate an install program as well, check out Software Installer for OS/2 by IBM. A demo of this tool is provided in the Development Tools section of The Developer Connection for OS/2, Volume 5. Software Installer features a CID-install and maintenance capabi lity. It also assists with the generating of diskette layout files.

For extra points, your company might decide to make a CD-ROM version of the product. Keep that in mind when the diskette layout process is being set up. For convenience and maintenance purposes, you will probably want to apply the same process to CD-ROM creation. For instance, in the case of the Developer's Toolkit for OS/2 2.1, the product diskettes were used to dump their contents to a hard disk scratch area for their subsequent incorporation into a CD-ROM. 

==The End of the Season==

The previous recommendations have taken you through the regular season play via file integration, virus detection, diskette, and CD-ROM creation. If you're ready for the post-season, look forward to an upcoming issue of The Developer Connection News. We will discuss installation, build verification testing, and propagation.

Remember "Winning isn't everything, it's the only thing..." V. Lombardi 

'''Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation'''


[[Category:Miscellaneous Articles]]