Article Figure 1 Figure 2 Figure 3 Figure 4
Figure 5 Figure 6 jan2007.tar

Configuration Management with ClearCase

Ramanathan Muthaiah

There is a famous quote attributed to Otto Von Bismarck saying, "If you like laws and sausages, you should never watch either one being made", which signifies the need to maintain distance from certain processes. However, in a software development setup, it is desirable to understand and refine processes periodically (resulting in continuous improvement). Processes, applied to software product development (including maintenance projects) environment, are influenced by the organization, which includes, but is not limited to:

  • Skill set of engineers
  • Team structure
  • Resources available for development needs

In an organizational setup, it is necessary to adhere to documented processes that aid software (SW) product development. Such processes are documented, and one such document is the product's Configuration Management (CM) plan. This plan, among other things, documents the strategy regarding development processes, release and delivery mechanisms, configuration control and procedures, and status reporting.

CMMI Definitions

This article discusses the various types of CM reports, highlighting their importance and needs. A standard definition of Configuration Management includes the following [1]:

  • Configuration Identification
  • Configuration Control
  • Status Accounting Audit
  • Review
  • Build Management
  • Process Management
  • Teamwork

Capability Maturity Model Integration (CMMI) gives the following definition for Configuration Management:

    "The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits".

Let's briefly look at the definitions of "configuration status accounting" and "configuration control":

    Configuration Status Accounting -- To record and report the status of components and change requests and gather vital statistics about the components in the product [1]. In the following sections, we'll look at a couple of specific reports, such as the baseline report and branching status report.

    Configuration Control -- To control the release of a product and changes to it throughout the product lifecycle to ensure consistency [1]. In the following sections, we shall see examples of Perl code that can be used to generate status reports and provide control mechanisms to monitor and track changes to configuration.

Baseline Reports

Using the right words in the right context is of utmost importance; otherwise, they can be misinterpreted [2]. Hence, it is imperative to understand what the word "Baseline" means in a project context [3].

Typically, "Baseline" refers to a stable set of configuration items released/delivered at a specific milestone in the project. A baseline report, among other things, should highlight:

  • Details (e.g., path within the storage repository) of configuration items that form the baseline
  • Baseline status (locked/obsoleted/released/approved)

As in other Perl scripts that are discussed in the rest of this article, ClearCase commands are embedded inside these scripts to achieve most of the functionality. Of course, there are alternatives [4].

IBM Rational ClearCase provides various metadata, such as branches, labels, attributes, etc. In most development environments, branches and labels are heavily used. Labels are almost always used to represent baseline identifiers.

In Figure 1, a baseline report is generated using the commands inside the Perl script:

  • cleartool find
  • cleartool desc

The baseline_report script shown in Figure 2 generates a comma-separated CSV file as output with ClearCase label as input.

Branching Status Report

In IBMRational ClearCase, "branches" are widely used (abused as well) form of metadata. Broadly, branches enable parallel development providing isolation from production/release streams. Thus, feature development, whose requirements are still evolving, can happen simultaneously at the same time as the regular development.

The branching diagram shown in Figure 3 provides an overview of development strategy applied to a medium-sized SW team setup. This simple and straightforward branching ensures that code changes to "RELEASE BRANCH(STREAM)" can be delivered only from "FEATURE BRANCH(STREAM)". Adherence to this branching policy is verified using the Perl script shown in Figure 4. Here again, the Perl script uses some of the ClearCase commands discussed in the previous section.

This Perl script also generates output in CSV format as shown in Figure 5. This CSV report, generated via the Perl script, highlights the specific parts of the source code in the repository that do not comply with the branching diagram shown in Figure 3. Using modules from CPAN, it is certainly possible to convert the CSV files to colorful reports and charts.

Guns and Triggers

"... Change is constant; change is inevitable", said Benjamin Disraeli. Likewise, in a software product, various configuration items regularly undergo change, either for maintenance reasons or to introduce new features or enhancements as requested by the customer. Such changes should be allowed to happen but in a controlled environment and this can be achieved using "trigger" mechanisms.

Perl scripts can be used to implement triggers in a SW development setup which uses IBM Rational ClearCase (base) for version-control purposes; triggers make possible changes to configuration items, done by SW engineers, technical writers and others, in a controller manner. This enabled CM/product librarian to monitor and track changes to the artifacts defined in SCM plan.

Some of the most common triggers are:

  • Forcing comments with minimum length during either check-in or check-out
  • Modifications of file/dir permissions to common user and group, after every check-in of the artifacts
  • Prohibition of duplicate artifacts in the repository
  • Restricting check-in/check-out from production and release branches
  • Validating check-ins against tickets/bug ids (from the bug tracking system)
  • Disallowing changes to obsolete/locked/released artifacts
  • Disabling removal of artifacts (without approval)

Of course, this list is not exhaustive. See the references for more information [5,6,7].

Some of these triggers, like restricting check-in/check-out and disallowing changes to obsolete/locked/released artifacts, can be implemented using certain system commands (e.g., /bin/false in Unix) without the need for Perl scripts. We shall see, in the following sections, how this can be done.

Minimum Comments

"To the good listener, half a word is enough", goes a Spanish proverb. It is wonderful and amazing to hear those who speak less but are able to convey the right meaning. Similarly, it is imperative to input valid and meaningful reasons while making changes to artifact(s). In IBM Rational ClearCase, provision of the "comments" metadata meets the needs.

The script shown in Figure 6 sets the required length and then calculates the spaces in the comments input by the developer. If the length is less than the expected length, then the operation is aborted using options of the command clearprompt. This forces the developer to provide comments of minimum length to complete the operation; however, this can be any sort of comment, including junk characters.

Overcoming "junk" comments may not be possible, but, if the bug tracking system allows interfacing via scripts, then this trigger can be enhanced to prompt the developer to provide a valid CR. This CR can then be validated against the bug tracking system and, based on the results, the operation(s) can either be allowed or disallowed.

Controlled Changes and Changes Controlled

This functionality is very much desirable, if the changes on the production branches is needed but should be limited/controlled. This can be implemented using a trigger (without using Perl script) using the command Cleartool mktrtype: 

cleartool mktrtype -element -all -preop checkin -c \
   "MY COMMENTS GO HERE" -brtype branch_name -nusers \
   user1,user2,user3 -execunix '/bin/false' -execwin '/bin/false' \
   MYNAME_FORTHE_TRIGGER@MY_VOBNAME
For complete understanding of the various options of this command, refer to the ClearCase manual pages.

For anyone who has been in the role of IBM Rational ClearCase administrator, this command should be quite simple and easy. The options nusers can have any number of usernames, but they must be the login names and not real names. We can also use commands from the respective operating environments, which is possible with the options execunix and execwin.

How to Invoke Scripts via mktrtype

In the previous section, we have seen that it is possible to invoke external scripts/commands via cleartool mktrtype. For reference needs, here is another example of this command, which invokes Perl scripts from network storage directories: 

cleartool mktrtype -element -all -preop checkin -c "MY COMMENTS \
   GO HERE" -brtype branch_name -nusers user1,user2,user3 \
   -execunix '$perl /path/to/Perl/script' -execwin 'ccperl \
   \\path\to\Perl\script' MYNAME_FORTHE_TRIGGER@MY_VOBNAME
Things to note here:

  • $perl -- Can be defined to a specific version of Perl because extra/customized modules are available
  • ccperl -- Perl that comes with IBM Rational ClearCase
  • \\path\to\Perl\script -- Windows notation to script's path is used, so that the Perl script can be invoked from the correct path, while the operation is done from Windows environment.

ClearCase and Environment Variables

All the Perl scripts (including the non-script implementation) discussed until now heavily utilize environment variables provided by the IBM Rational ClearCase application. To know which (environment) variables are available for scripting from IBM Rational ClearCase, refer to the following manual pages.

  • cleartool man mktrtype
  • cleartool man env_ccase
  • cleartool man events_ccase

Conclusion

Charles Darwin said, "It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change". Thus, it must be emphasized that, one must not be resistant to changes but make sincere attempts to thoroughly understand them, so that adaptation is easier and smoother.

References

1. Dart, Susan A. 1992. The Past, Present, and Future of Configuration Management. Carnegie Mellon University, Software Engineering Institute.

2. Haas, Anne Mette Jonassen. 2002. Configuration Management Principles and Practice. From Chapter 1, Sec. 1.6: "False Friends: Version Control and Baselines". Addison-Wesley Professional.

3. Longacre Inc. Blog entry -- http://www.longacre-inc.com/blog/index.php/2006/02/defining-baseline#more-11

4. CPAN Resources http://search.cpan.org/~dsb; http://search.cpan.org/search?query=clearcase&mode=all

5. Diebolt, Daniel. 2004. "IBM Rational ClearCase: The ten best triggers" -- http://www-128.ibm.com/developerworks/rational/library/4311.html

6. Buckley, Christian and Darren Pulsipher. 2004. "Conjunction junction, what's your function: More ClearCase integration strategies" -- http://www-128.ibm.com/developerworks/rational/library/4139.html

7. Buckley, Christian and Darren Pulsipher. 2004. "Trigger happier: More tools for overcoming entropy in software engineering" -- http://www-128.ibm.com/developerworks/rational/library/4127.html

Ramanathan Muthaiah graduated from ACCET, Karaikudi (in India) with a degree in Electronics & Communication in 1995. He is currently working as CM lead in Infineon Technologies India Ltd, and has more than 10 years of experience in customer support, network and systems administration, and configuration management. When not playing with his daughter, he likes fiddling with GNU/Linux software on his home PC (running Fedora core 5, hoping to have Debian Etch in the near future). He can be reached at: ramanathan.muthaiah@infineon.com.