When you build the products, capture the output of the build process in a log file. Review the log carefully for errors or indications of problems in the build. (If your builds are automated through a batch file or script, you can direct the output into a log file.)
Control the build environment carefully. Because the build environment is partially defined in your makefiles, review makefiles checked in by developers to verify that they are clean.
For example, developers check out a makefile and customize it to reference their test version of a library file, then accidentally check in the makefile. (Now the build management build references the developers test libraries, and causes build problems.)
When compiled, a Java source file can produce many class files, some of whose names are not fixed and known in advance. A class file for an anonymous inner class has a name with a sequentially numbered suffix. If you control Java class files, the history of an object with a temporary name is not meaningful. The temporary name refers to different anonymous inner classes at different times. Furthermore, if a class is removed, the Java compiler does not delete a previously existing class file for that class. You must remove the corresponding object from the project manually. If you work around naming by deleting all class files before compiling, then all your controlled class file products seem to change in every build.
Instead of controlling the class files, build a jar file (or ear or war file, as appropriate for your application) and control that.
If scripts and tools build your product, consider controlling these scripts and tools in the database. Keeping controlled copies of the right versions of the tools used to build each release of your software makes it easier for you to rebuild older releases, and to build patches to older releases. You might also need access to older machines and operating systems.
Ensure that uncontrolled product files are writable by multiple build managers.
Most teams control top-level products, such as libraries and executables, but not intermediate products, such as .obj files. Intermediate products can get big. If you control them, your database grows quickly because users create many different copies of the product files. Uncontrolled products exist only in your work area.
Because products are uncontrolled, Rational Synergy does not set owner or access permissions. Therefore, you must take extra steps to ensure that multiple build managers can update the uncontrolled products in the work area. If a build manager creates uncontrolled products with permissions that only he can modify, a different build manager cannot rebuild the project without deleting the uncontrolled products.
To ensure that uncontrolled products are writable by multiple build managers, perform the following steps:
Alternatively, update your build scripts or makefiles to delete intermediate products before building them or to change the file permissions to set the group and allow group write access after building them.