Aims of This Chapter

The main reason for generating baseline and change request reports is to be able to ascertain the content of a build or release. The difference between baseline and change request reports is as follows:

• Baselines allow you to ascertain this content at a file level, identifying the complete set of element versions. With baseline reports you can identify the difference between builds and list the exact content of any build so that you can regenerate or examine it in the future.

• Change requests allow you to ascertain content at a functional level, identifying the modified set of activities, such as defects, enhancements, or features. With change request reports you can identify why a build is being created and establish its suitability for subsequent testing or releasing.

Note that there is something of a similarity between these two types of reports and what Configuration Management typically calls a Physical Configuration Audit and a Function Configuration Audit.

The generation of change request reports links back to the identification phase described in Chapter 1, "Introduction to Software Build and Release Management." During day-to-day development, when builds are being carried out frequently, change request reports allow project leads and management to identify the functionality in each build for monitoring and testing purposes. As you move toward release time, using the content of these reports is fundamental to being able to make proactive decisions about what and when to build and release. After reading this chapter, you will be able to

• Generate a basic baseline report (for both Base ClearCase labels and UCM baselines) using the ClearCase command line.

• Generate formatted baseline reports using Perl.

• Generate a basic change request report using Perl and the ClearQuest API.

• Generate a release note containing a consolidated set of change requests.

• Generate an RSS feed from ClearQuest change requests.

• Automate the execution of reports using Ant.

The mechanisms used in this chapter also will be of direct use in the next chapter, when we look at how to publish more sophisticated reports onto a project Web site or intranet.