Automation in ClearCase Administration

IBM Rational ClearCase is widely used as a software configuration management tool in many global organizations along with IBM Rational ClearCase Multisite. The latter enables distributed software development to be in sync (i.e., development done from distributed geographical sites to be visible/accessible throughout the organization).

The targeted audience for this article is ClearCase administrators, systems administrators who are responsible for managing ClearCase installations, and those who develop tools around IBM Rational ClearCase and IBM Rational ClearCase Multisite.

This article does not discuss the features available in IBM Rational ClearCase and IBM Rational ClearCase Multisite. The objective of this article is to highlight, with real-world examples, some of the various administration and development-related activities that can be automated using Perl/Shell scripts. Such automation will eventually reduce errors arising from manual execution and thus save time and effort on the part of administrators and developers. This will be looked at first from an administrator's perspective and then from a developer's perspective.

The following sections' primary focus is ClearCase clients on Unix operating systems and not Windows. Wherever applicable, as the topic demands, I will discuss both platforms.

ClearCase Administration

ClearCase Multisite utilizes the WAN infrastructure, available in an organization, as the transport medium to transmit and receive synchronization packets to keep the code repositories located in various sites of the organization's intranet, in sync. ClearCase Multisite provides a "scheduling mechanism" that can be used within automation scripts to import and export the synchronization data. In IBM Rational ClearCase, the code repository is termed as VOB -- Versioned Object Base. Typically, as per the project requirements, new VOBs are created by the CM (Configuration Manager) or ClearCase administrator. These new VOBs together with existing VOBs (re-used from other previous/current projects) are then used for software development across all the sites.

Creation of VOBs/Replicas

From time to time, new VOBs must be created, and tasks such as creating multisite replicas, installing triggers in the local replica, and enabling multisite sync with other replicas may also be required. These and other tasks form part of the roles and responsibilities of a project CM or site ClearCase administrator. Repetition of such activities calls for careful attention because the risk of making mistakes is much higher with manual execution. Thus, the following can be considered as use-cases for automation:

1. Provide error-free execution environment.

2. Log execution results for further analysis.

3. Enhance productivity by saving on time and effort.

As shown in Figure 2, the VOB/replica creation script is invoked from the bash prompt. Here the list of vob-tag names is stored in a flat ASCII file, and the Perl script is then invoked from within a "for loop" construct. Required inputs to the Perl script are substituted with variable values in the "for loop".

Figure 2 also shows the working of the VOB/replica creation Perl script where it does initial checks (e.g., checking for the existence of the VOBs/replicas). If the check is successful (i.e., if the VOBs/replicas are not already available), then they are created.

In IBM Rational ClearCase, it is recommended practice to create multiple regions to accommodate the different network file-system naming conventions of Windows and Unix operating systems. In our example, the VOBs are first created and registered in the "unix" region and then tagged or registered in the "windows" region. For the latter, I will show another Perl script in the next section.

After the VOBs are created or installed, multisite can be enabled. In the Perl script, this can be done using the optional input, "multisite", thus allowing the ClearCase or systems administrator to decide whether to enable multisite. This is shown in Figure 3.

The script accepts the name of the remote site for which the replica packet should be created and transmitted. This name is in a shorter format and the convention shown is purely environment-specific. Within the Perl script, a table is maintained that maps the different valid remote site names and their corresponding ClearCase shipping server names.

Shipping servers perform the function of transmitting and receiving synchronization data or packets between ClearCase servers located in different networks within the intranet. Based on the type of the VOB (production or customer VOB), which is determined based on pre-defined and documented vob-tag naming conventions (again environment-specific), the corresponding remote site server name is chosen and the replica is created and transmitted to the remote site immediately.

Note that the transmission of the replica packet to the remote site can be deferred from immediate transmission; this option is not available in our Perl script but can be enabled with the multitool mkreplica command. To learn more about this, please refer to the IBM Rational ClearCase MultiSite documentation.

Windows Tag(s) Registration

As mentioned in the previous section, newly created VOBs/replicas are first registered and tagged in the "unix" region and next in the "windows" region. Now let's focus on another Perl script that does the latter. As usual, initial checks are done before tagging the VOBs/replicas in the "windows" region (Figure 4). Some of these checks include validating the existence of vob-tags in "unix" and "windows" regions.

Now that I've presented two automation scripts, let's look at the benefits of such scripts. Table 1 shows the time spent in these activities (discussed previously) and highlights the productivity gains.

Monitoring and Reporting

In IBM Rational Clearcase, repositories or VOBs are accessed using Clearcase views. In the CVS or Subversion world, these views are known as workspaces or working copies. Of course, to access the desired files and folders in the repositories, you would need a valid "configuration specification" or "config spec" associated with the view. To learn more about the working details of "config spec", please refer to IBM Rational ClearCase documentation.

Generally, the tool does not restrict on the number of Clearcase views that can be created by any individual. But the restriction on the number of views can be enforced as part of development policies followed at a project or organizational level.

With no restrictions on the number of ClearCase views, it is mandatory to monitor and control their usage because each view consumes some amount of disk space. This monitoring is especially important when the view storage (folder space where the views are created) is network-based and project-specific. Generally, ClearCase views can be used either as read-only or to do software builds. In the latter case, disk space consumption grows higher and higher as the code and its dependencies get bigger and bigger. The demand for disk space increases as more and more such build views are created for similar needs.

Thus, it is essential to periodically generate statistics, to report on the usage of disk space, and also to do capacity planning for future growth. We can do this using a simple combination of Unix commands like xargs, sed, awk, and grep. We will filter the output to consider those views that are real heavyweights (i.e., those that occupy space beyond a certain threshold level). See Figure 5.

The output is sorted in descending order showing which view has used how much disk space. It is possible to add the mail command and send out this report.

Automation in Development Environment

Thus far, I've focused primarily on the administrator's perspective; now let's shift our attention to developers and their development environment. In any software development project, every developer should have access to the code repository to complete assignments and meet project deadlines. In IBM Rational ClearCase, code repositories or VOBs are accessible by only using ClearCase views.

ClearCase view and a set of associated rules (known as "configuration specification" whose syntax is pre-defined in ClearCase) determine which version of the code or documentation in the VOBs is visible from this view. To help developers stay focused in their core responsibilities, it is best to train them on the tool and enable provisions to simplify the tool usage (without memorizing the numerous arguments and options that go with each ClearCase command).

Scripting View Creation

The best and the most common means of simplifying such tasks are via wrappers (scripts written using Shell, Perl, VB, etc.). Let's start with a simple wrapper, written in Perl, which is used to create ClearCase views (only dynamic and not snapshot). See Figure 6.

As this figure shows, using raw ClearCase commands with the multiple arguments and options can be quite cumbersome. Additionally, in order for these views to be accessed on Windows ClearCase clients, they must be exported manually to Windows (using the region synchronizer tool available in ClearCase clients running on Windows).

As a general practice, many software organizations have development policies to have uniformity in view-tags (i.e., naming conventions for ClearCase view-tag names). Typically, this is achieved by using scripts or tools and will be covered in the coming sections.

In Figure 7, we are running a Perl wrapper, mkview, from the Unix command line. This script creates a ClearCase view (of type dynamic) and automatically exports or synchronizes the view to the "windows" region as well. Note that the view-tag created thus is prefixed with the userid of the person running the script. It is possible to have the view-tag created as either public (accessible to only the user who created the view) or private (accessible to only the person who created the view). For more on public and private VOBs and view-tags, please refer to IBM Rational ClearCase documentation.

Automated Labeling

In IBM Rational ClearCase, the most used metadata (available to developers, build engineers, integrators, release managers, etc.) next to branching is labeling. Labels provide a mechanism to track what was released to whom and when. Labels may be used for different purposes -- to identify releases, bugfixes, hot-fix patches, development milestones, etc.

For this discussion, let's look at the case of labels used for development needs. Such labels may be used to indicate the progress of development. Figure 8 shows a simple example of such a development label. Next, I will show how this script applies to development environments.

The labeling script in Figure 9 does essential checks to validate the environment and the inputs provided before proceeding to executing the expected functionality of creating and applying labels. Some of these checks include:

• Checking the label name for uppercase and rejecting (exit the execution) if label name is in lowercase.
• Checking whether vob-tags input are valid and warn of invalid vob-tag names.
• Exiting if not executed from a ClearCase view context.

The script can be extended further to parse the ClearCase view config spec and extract the vob-tag names, which can then be used as inputs to this script.

Conclusion

I have described some examples of Clearcase administration and development tasks and shown how such tasks can be automated to ease day-to-day work and thus increase efficiency and enhance productivity.

Many other activities than those discussed here can be considered for automation, such as parsing config spec to determine which vob-tags should be mounted, enhancing the mkview script to create snapshot views (apart from dynamic views), automating development views' config spec creation corresponding to the feature development, etc.

Please note that implementation of automated scripts/tools that aid software development in distributed organizations should be handled with utmost precaution and care, ensuring that all the centers are using the same version of the tools at any given time. Naturally, IBM Rational ClearCase (with MultiSite) can solve such issues of keeping multiple sites in sync and help administrators and development teams in the process.

Ramanathan holds a Bachelor's Degree in Electronics & Communications Engineering, Karaikudi, India. He is currently working as CM lead at Infineon Technologies, India and has 10 years of IT experience spanning customer support, systems administration, Cisco lab admin, and build and release engineering. His areas of expertise include IBM Rational ClearCase (base), Perl scripting and Unix systems administration.