8. Software Builds

This section deals with the best practices for software builds. Build is the process of creating the application binaries for a software release. They are done in a periodic manner by the build teams to provide baseline binaries for daily work.

8.1. Build Early and Build Often (BEBO)

A variation of this adage has been around in the Open Source community called "Release Early and Release Often" for quite some time albeit for a different reason. BEBO helps a development team identify issues that can arise from checking in the wrong files. BEBO will address integration issues at the application level that might have slipped passed individual developer builds. It will also improve the team morale when they see a working version of the application.

Builds must be done on a regular basis. There should be a dedicated resource(s) assigned to do the same. The entire project team must be trained to view the daily build as an important activity and not as a chore. Builds must be completed without any failures on a regular basis. Build failures must be a rare event and should be treated with utmost seriousness. The project team should ensure that successful builds are top priority on their agenda. The seriousness can be emphasised by setting up a penalty for breaking the build.

Each build can be tagged in CVS using a standard naming convention. This can help developers checkout a working version of the entire system from daily builds for local development.

8.2. Automate build Process completely

Another key practice for software builds is to automate the build process completely. The automation process must also include automatic retrieval of the right source files from the CVS repository. This ensures that the build process is completely repeatable and consistent. In addition, the chances of a build with the wrong version of the application source files are reduced to a large degree.

By automating the build process, the task of building often becomes less burdensome.

8.3. All necessary files must be checked-in before build

This adage sounds trivial at first but this problem is very common even with experienced development teams due to oversight. The problem of oversight cannot be easily addressed since the onus is on the individual developer to ensure that his or her file has been checked in. This practice should be drummed into the team in the form of training and pre-build announcements to ensure that the right version of source code is available in the repository.

Automated build process as explained above will help in catching this problem to a certain degree since they will automatically take the source code from the CVS repository and perform the software build. Any missed items will surface during the build process itself (makefiles etc.,) or during the regression testing of the product (older version of the file checked in).

A penalty based system can be setup to handle wrong check-in. Having a kitty for a post project party to which each person who makes a wrong check-in will contribute a fixed amount will act a good penalty system.