When you build the products, capture the output of the build process in a log file, then 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.)
Be sure to control the build environment carefully. Because the build environment is partially defined in your makefiles, you will need to review makefiles that are checked in by developers to verify that they will not adversely affect the build environment.
For example, a developer could check out a makefile and customize it to reference his personal test version of a library file, then accidentally check in the makefile. (That would cause the build manager’s build to reference the developer’s test library, and is likely to cause problems at some point.)
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 will have a name with a sequentially numbered suffix. If you attempt to control Java class files, the history of an object with such a name will not be meaningful because it could refer to different anonymous inner classes at different times. Furthermore, if a class is removed, the Java compiler will not delete a previously existing class file for that class, so you will have to remove the corresponding object from the project manually. If you attempt to work around this by deleting all class files before compiling, then all your controlled class file products will appear 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 you have scripts and tools to build your product, you should consider controlling these scripts and tools themselves in Rational Synergy. 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. Remember that you might also need to keep access to older machines and operating systems.
Ensure that uncontrolled product files are writable by multiple build managers.
Most teams do not control all of their products within Rational Synergy. It is common to control top-level products, such as libraries and executables, but not to control intermediate products such as .obj files, since these files can be very big. If you control them, your database will grow quickly because many different copies of the product files will be created by different users. Uncontrolled products exist only in your work area.
Because products are uncontrolled, Rational Synergy does not set their owner or access permissions. Therefore, you need to take some extra steps to ensure that multiple build managers can update the uncontrolled products in the work area. If uncontrolled products are created with permissions that only the build manager who created the file can modify, another build manager will not be able to rebuild the project without first deleting the uncontrolled products.
To ensure that uncontrolled products are writable by multiple build managers, perform the following steps:
Alternatively, you can update your build scripts or makefiles either to delete intermediate products before building them, or to change the permissions of those files to set the group and allow group write access after building them.