Continuous integration with IBM Rational ClearCase Remote Client

Agile development practices with CruiseControl

Comments

IBM® Rational® ClearCase® is software configuration management (SCM) software that supports most of the current development modes. These days, agile development has become increasingly popular. However, SCM software is an inseparable part of software development, and its impact on efficiency is significant. ClearCase Remote Client is a lightweight client for ClearCase. Version 7.1 introduces features that support agile development.

Continuous integration (CI) is one of the best practices of agile development. It is very critical to apply effective supporting tools to implement CI successfully in your software development life cycle. This process includes an SCM tool (in this case, ClearCase Remote Client), and a tool to automatically run your build and report its results (in this case, CruiseControl). This article shows you how to implement CI with CruiseControl and ClearCase Remote Client.

There are multiple versions of ClearCase Remote Client; the examples in this article use ClearCase Remote Client V7.1. For convenience, this product is referred to simply as ClearCase Remote Client.

Prerequisites

The authors of this article assume that you have basic knowledge of CruiseControl and Apache Ant. If you do not, see Resources for links to Web sites where you can get more information.

Agile development

Agile software development represents a group of software development best practices. As the name implies, it means high-speed coding, quick reaction to requirements changes, short iterations, and rapid delivery of high-quality software. All of its characteristics are based on these principles. Agile development favors:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Most iterative and incremental development models are designed to enable teams to deliver high-quality software as quickly as possible. However, it typically takes much more time for teams that use traditional development models to release software. This is because the models predefine all of the stages, and you must step through each of them. Therefore, the models are not that flexible. In contrast, agile development is more adaptive: it delivers software with the smallest workable functionality and improves gradually.

Later sections of this article contain detailed information about how ClearCase Remote Client supports agile development. The next section provides a brief introduction to CI.

Continuous integration

In agile development, developers frequently send their work to an integration workspace. The large number of builds makes the integration not only complex but also costly. CI helps with this.

In considering the advantages of using CI, first, consider the daily work of developers. As a start, developers get the latest and consistent source code from the repository, and then they develop for a certain period of time before delivering their versions from the local workspace to the integration repository. Different deliveries from different developers cause conflicts and inconsistency. As a result, the integration build becomes very complex and expensive.

Fortunately, there is software that performs an integration build and even smoke tests after every delivery, automatically. CI is a practice that helps achieve this goal. Martin Fowler defined CI this way in the preface to his article titled "Continuous Integration:"

Continuous integration is a software development practice where members of a team integrate their work frequently. Usually, each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Kevin Lee's article in The Rational Edge, titled "Realizing continuous integration," also provides a good introduction. For the purposes of this article, CI is a software development practice in which integration, build, and smoke testing of the build happen continuously.

Considered as a practice, CI is a cyclical process that consists of three main steps:

  1. The update of the integration repository
  2. The integration build
  3. Feedback

Figure 1 shows the relationship among these three steps.

Figure 1. Infrastructure of CI
Two clients interact with SCM and CI servers
Two clients interact with SCM and CI servers

The first step (update the integration repository) is accomplished by SCM software. The second step (the integration build) is achieved through a build tool. The last step is carried out by a kind of tool that has been developed according to the principles of CI to launch these steps automatically (for example, CruiseControl, an open source framework for a continuous build process). In the examples in this article, CI will be implemented using the ClearCase Remote Client and CruiseControl software tools.

The following section describes the new features of ClearCase Remote Client in detail and explains how this tool meets the requirements for successful SCM software.

Features of ClearCase Remote Client V7.1

To support agile software development, the IBM team for Rational software developed a remote client for ClearCase and called it, logically enough, ClearCase Remote Client. It supports most of the functionality of Rational ClearCase, with an easy-to-use user interface (UI).

There are two kinds of ClearCase Remote Client.

  • One is the ClearCase Remote Client Eclipse plug-in
  • The other is the ClearCase Remote Client stand-alone version

In this article, unless stated otherwise, "ClearCase Remote Client" refers to the Eclipse plug-in.

Next, you'll see how ClearCase Remote Client supports agile development.

Compacted Navigator view

All of the contents in ClearCase Remote Client are compacted into the ClearCase Navigator view and are organized in a hierarchy. You can find and edit any of these contents easily and quickly. To make it more intuitive, the UI uses illustrations.

In Figure 2, you can see that there are two main parts: the first is local views and contains all of the local snapshot views, and the second is the server information.

Figure 2. ClearCase Navigator
Local Views and 2. Server Information
Local Views and 2. Server Information

In the second part, there are also two subparts. One is ClearCase, and the other is ClearQuest (IBM® Rational® ClearQuest®), as shown in Figure 3.

Figure 3. ClearCase Navigator: server information
two branches expanded in an explorer view
two branches expanded in an explorer view

Under ClearCase”, both Component VOBs (Versioned Object Bases) and Project VOBs are listed. You can modify two kinds of metadata under Component VOBs: Branch Types and Label Types.

Under Project VOBs, all of the project VOBs are listed. And under each project VOB, projects, integration stream, development streams, and baselines are all displayed, as shown in Figure 4.

As you can see, the hierarchy and combination of all elements make the outlook of ClearCase Remote Client concise and easy. That’s one of the important characteristic agile software development requires.

Figure 4. ClearCase Navigator: project information
Project's VOB expanded in explorer view
Project's VOB expanded in explorer view

Outstanding features

Generally, ClearCase Remote Client functionalities can be placed in two categories: development and management. As examples, you can use development functionalities to:

  • Create a view or join a project (which will generate views)
  • Edit configuration specifics
  • Add elements into source control
  • Modify elements through checking out or in, or hijacking

If the view is a development view for a project, then both delivering and rebasing are supported. Except for these functionalities for development, some management functions are also available. You can do the following tasks, for example:

  • Modify, add, or delete two kinds of metadata listed for component VOBs
  • Create and recommend baselines for project streams

These functionalities are very common, so you might expect that any SCM tool would support them. There are three main features that make ClearCase Remote Client more useful, though, and the following sections discuss them one by one.

Pending Changes view

In ClearCase Remote Client, as in other SCM tools, developers work in separate workspaces so that they can develop in parallel. Eventually, though, they have to integrate their works together. In ClearCase Remote Client, the deliver and rebase functions achieve that work.

In other SCM software, you cannot check the differences between different workspaces until after the merger finishes. However, in the ClearCase Remote Client Pending Changes view, shown in Figure 5, you can check all of the differences between the local workspace and the target workspace (which is usually the integration workspace) before the merger starts.

Figure 5. Pending Changes view
activities expanded in explorer view
activities expanded in explorer view

Pending changes are categorized into three kinds:

  • Incoming changes, which means that there are no changes in the local workspace, but there are changes in the target workspace
  • Outgoing changes, which is the opposite of incoming changes
  • Conflict changes, which means that changes exist in both the local and the target workspace.

    In the base ClearCase view, pending changes are grouped according to elements hierarchically. In the development view of your project, they are grouped by activities.

In the Pending Changes view, you can see the element differences of element using the comparison tool, and then synchronize the workspace.

What’s more, ClearCase Remote Client provides a pending changes schedule is provided. With this functionality, you can schedule the Pending Changes view so that pending changes can be collected and displayed automatically at predefined times or at regular intervals.

These mechanisms facilitate the integration process considerably. As a result, you can save a lot of time. This is a very important outstanding feature of ClearCase Remote Client, and makes it a good fit for agile software development.

Aggregate action

During development, the following situations almost always arise:

  • Multiple source code needs to be added into source control when you initialize workspace
  • Check out and in, hijack, and undo the checkout or hijack, both for a folder and its subelements
  • Find the checkout or hijack under a folder.

    It would take the developers lots of time if all of these actions had to be done one by one. Fortunately, ClearCase Remote Client provides aggregate actions. For the first two cases, you can select to contain subelements. And for the last case, aggregated change decorations are propagated to the top level of a hierarchy if changes exist at any level of that hierarchy.

    In addition, you can perform operations such as check in, undo checkout, and undo hijack aggregately, on any node with that decoration. This feature makes the development process go much more smoothly.

ClearQuest integration

As shown in Figure 3 previously, ClearQuest is integrated into ClearCase Remote Client. ClearQuest is change request management software, and Unified Change Management (UCM) is a solution for managing change across the development lifecycle. The integration makes ClearCase Remote Client support UCM.

Integration with ClearQuest means that the activities are centrally managed by ClearQuest. This enables your developers to focus 100% of their energy on developing. As a result, your project will grow faster.

Implement continuous integration

The previous sections introduced you to agile software development, CI, ClearCase Remote Client, and CruiseControl. You've also seen some of the ways that ClearCase Remote Client supports agile development. In this section, you will learn how to implement CI with CruiseControl and ClearCase Remote Client under the Microsoft® Windows® platform. First, a typical infrastructure for CI will be provided, and then an example of CI under this infrastructure will be implemented.

Typical infrastructure for CI

To achieve CI, you need some tools, including SCM software (ClearCase), a build tool, and a tool that executes and reports the build automatically (CruiseControl). Figure 6 shows a typical infrastructure for CI. As you can see in Figure 6, there are three parts:

  • Development
  • Integration build
  • Feedback

The first part is development: developers develop software by editing source code under SCM software control. The second part is the integration build: people in charge of this part are responsible for implementing CI, as discussed in this article. Within CI, an automated tool such as CruiseControl configures and schedules the integration build.

After a new build process is started, CruiseControl invokes a build tool such as Ant to carry out predefined tasks, including:

  • Updating source code
  • Compiling
  • If necessary, Java™ unit (JUnit) testing

After build comes the last part of the CI infrastructure, feedback. After the integration build, CruiseControl sends results to the developers through several kinds of methods (for instance, e-mail, Web notifications, and so on). A summary of the workflow of CI will be provided in the Workflow of CruiseControl section.

Figure 6. Infrastructure of CI
client and CM, Web, SMTP, and Build servers
client and CM, Web, SMTP, and Build servers

Theoretically, if the only supported functionality is source code transactions between SCM software tools, your integrators might use different SCM software than your developers. However, for convenience and clarity, this article assumes that both developers and integrators use ClearCase Remote Client as their SCM software. As a result, source code can be retrieved or updated directly during the integration build.

Figure 6 shows that a Rational ClearCase Server is needed. You should have a basic understanding of this Server. If not, refer to the Resources section for more information.

The following sections will describe a step-by-step implementation of CI:

  1. Initialize the environment
  2. Configure CruiseControl
  3. Update the source code using a Java program

In the Initialize the view section, you will learn how to initialize the ClearCase Remote Client environment. The Set up CruiseControl section describes how to set up CruiseControl. The Configure CruiseControl section discusses CruiseControl configuration, and provides an example of the relevant files.

Before you build the source code, an update is necessary. This functionality is achieved using a Java program with a Configuration Management application programming interface (CM API), which process is discussed in the CruiseControl workflow section.

In the last section of this chapter, you will draw a workflow of CruiseControl.

Initialize the environment

As you know, you can only access the repository in ClearCase through views. Therefore, you should first initialize the view that will be used by the integration build to access source code. After that, you will set up CruiseControl.

Initialize the view

Suppose that the ClearCase V7.1 server has already been set up successfully. Your next steps are to:

  1. Set up Eclipse V3.3.x
  2. Install ClearCase Remote Client V7.1 as a plug-in against Eclipse
  3. Create, view, and modify the configuration specification, and then load VOBs

Set up CruiseControl

There are two parts of this tool configuration: CruiseControl and Tomcat. Tomcat is used as a Web server to deploy feedback about the integration build through the Web.

  1. Install CruiseControl.
  2. Install Tomcat.
  3. Deploy CruiseControl in Tomcat according to the following steps.
  1. Stop Tomcat
  2. Copy install_path_cruisecontrol\webapps\cruisecontrol to install_path_tomcat\webapps (where install_path_cruisecontrol represents the location where CruiseControl is installed, and install_path_tomcat means the path where Tomcat located).
  3. Start Tomcat.
  4. Check the result. To do so, input the following URL in your browser: http://localhost:port/cruisecontrol. “Port” is the port that you specified for Tomcat. The default value is 8080.

Configure CruiseControl

There are two main files for CruiseControl: a configuration file and a build file. This section introduces them, and then shows you how to create them. It also describes in detail a Java program that you will use to update source code automatically.

Configuration file

You use the configuration file, config.xml, to configure CruiseControl. It should be placed directly under the installation path of CruiseControl. For example, the full path and name for the configuration file in this example is C:\Program Files\CruiseControl\config.xml.

Generally, in this file, you should specify the following:

  • The status of CruiseControl
  • The location of Ant
  • The SCM software that the source code is under the control of
  • The directory where the source code is placed
  • The location of the build file
  • The logs directory for the build results

This article does not give you a detailed description of how the configuration file should be written, because you can find a tutorial about how to do so at install_path_cruisecontrol\docs\main\configxml.html (where “install_path_cruisecontrol” represents the installation path of CruiseControl).

As it is defined, the subelements under the element modificationset indicate to CruiseControl what kind of SCM the source code is under control of, and the location of the source code. The clearcase subelement means that the source control is under control of Rational ClearCase, while the file system subelement indicates that the source code is not under the control of any SCM software. At first glance, it seems obvious that you should use the clearcase subelement, because the source code that you are using in this example is under the control of ClearCase.

However, if you do use the clearcase subelement, and point the location to the copy area of the snapshot view, an error will occur telling you that the source is not under control. This is easy to understand. From the perspective of the operating system, the source code under the copy area of the snapshot view is only typical files and directories. The reason they are considered under source control is that the file .copyarea.dat is under the root directory of the snapshot view. However, CruiseControl doesn’t recognize this file, so you must use the file system subelement.

Another problem may occur to you: how can you update and build the source code? You can accomplish these actions using a build tool such as Ant. The location of the build file should be provided in the configuration file. The build file will be discussed in more detail in the following section.

Listing 1 shows an example of a configuration file.

Listing 1. Configuration file
<cruisecontrol>
  <project name=”helloworld”>
<bootstrappers>
  <currentbuildstatusbootstrapper file=”currentbuild.txt” />
</bootstrappers>
<modificationset quietperiod=”300”>
  <filesystem folder=”D:\views\View_CI\VOB_CI\helloworld” />
</modificationset>
<schedule interval=”10”>
  <ant antscript=”apache-ant-1.7.0\bin\ant.bat” 
	buildfile=”D:\ views\View_CI\VOB_CI\build.xml”
	target=”masterbuild” multiple=”1” />
</schedule>
<log dir=”logs\${project.name}”>
  <merge dir=”test-results”/>
</log>
<publishers>
  <currentbuildstatuspublisher file=”currentbuild.txt” />
  <onsuccess>
  <artifactspublisher dir=”C:\Program Files\CruiseControl\logs\${project.name}” 
dest=” C:\Program Files\CruiseControl\Tomcat4.1\webapps\cruisecontrol\artifacts”>
</onsuccess>
<onFailure>
  <artifactspublisher dir=”C:\Program Files\CruiseControl\logs\${project.name}” 
dest=” C:\Program Files\CruiseControl\Tomcat4.1\webapps\cruisecontrol\artifacts”>
</onFailure>
</publishers>
  </project>
</cruisecontrol>

Build file

The build file lists all of the tasks that the build tool should do. The name of the build file is build.xml, and you can put it in any location. The configuration file should point to the full or relative path. In this example, you use Ant as the build tool.

Generally, there are four parts in a build file:

  • Prepare the environment
  • Update the source code
  • Compile the source code
  • Clean the environment

This article will only discuss updating the source code. There are embodied commands to update source code for subelements such as clearcase, cvs, or others under the modificationset element in the configuration file. The previous section explained, however, why you need to use the filesystem subelement. So you have to make the snapshot view update automatically using the build tool.

Fortunately, ClearCase provides a CM API with which you can write a Java program to update your snapshot view automatically. The method for doing this is as follows:

  1. Write a Java program using the ClearCase CM API to update the snapshot view
  2. Call this program in the CruiseControl build file.

Detailed information about this program is described in the next section.

Listing 2 gives an example of a build file.

Listing 2. Build file
<project name="helloworld" basedir="." default="all">
  <!--property name="build.compiler" value="javac"/-->
  <!--property name="build.compiler.emacs" value="true"/-->
  <property name="build.dir" value="classes"/>
  <property name="dist.dir" value="dist"/>
  <property name="source.dir" value="D:\views\View_CI\Vob_CI\helloworld"/>
  <property name="ccdir" value="C:\Program Files\CruiseControl"/>
  <path id="Update_View.classpath">
    <pathelement location="D:\java workspace\Update_View\bin"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-codec-1.3.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-httpclient-3.0.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-logging-1.0.4.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/remote_core.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpcc.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpcmmn.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpwvcm.jar"/>
  </path>
  <target name="init" description="Prepare for build">
    <mkdir dir="${build.dir}"/>
    <mkdir dir="${dist.dir}"/>
  </target>
  <target name="clean" description="Clean all build products">
    <delete dir="${build.dir}"/>
    <delete dir="${dist.dir}"/>
    <mkdir dir="${build.dir}"/>
    <mkdir dir="${dist.dir}"/>
  </target>
  <target name="Update_View">
    <java classname="update_view.Update_View" failonerror="true" fork="yes">
       <classpath refid="Update_View.classpath"/>
    </java>
  </target>
  <target name="compile" depends="init,Update_View" description="Compile app">
    <javac srcdir="${source.dir}" destdir="{build.dir}" 
       includes="**/*.java" debug="on" deprecation="true"/> 
  </target>
  <target name="all" depends="init,clean,Update_View,compile" description="Build app"/>
  <target name="masterbuild" depends="compile" description="Master build"/>
  <target name="cleanbuild" depends="clean, masterbuild" description="Clean build"/>
</project>

Program to update the source code

This section discusses in detail the program to update your source code.

Generally speaking, the Java program that automatically updates source code is a client application that uses some of the CM API to scan elements that are under source control in a certain location, and then update them.

First, look at how the CM server deals with requests from the client application. Figure 7 shows the relevant architecture.

Figure 7. Architecture of the CM API
Client app, subproviders, and Rational products
Client app, subproviders, and Rational products

Figure 7 shows that the CM API provider dispatches requests from a client application to product-specific subproviders.

Now, examine how these CM APIs are organized. The CM APIs are packaged into four packages, javax.wvcm, com.ibm.rational.wvcm.stp, com.ibm.rational.wvcm.stp.cq, and com.ibm.rational.wvcm.stp.cc.

How do you install the CM API? It is very simple. From the infrastructure of the CM API, you know that each individual product installation includes the common component and the product’s Rational CM API subprovider. Thus, depending on the combination of products installed, systems might have all or a subset of the following Java archive (JAR) files:

  • Rational CM API component infrastructure JAR files
  • Rational CM API subprovider JAR files for ClearCase
  • Rational CM API subprovider JAR files for ClearQuest

Where are these files located? By default, the Rational CM API JAR files (and other required JAR files) are installed under the common installation path for Rational products.

Now, you have a basic knowledge of the architecture of the CM API. Next, you will construct the Java program step by step.

  1. Create a Java program. Figure 8 shows a screen capture of the program, Update.java.
Figure 8. Java program
file shown in tree view in Package Explorer
file shown in tree view in Package Explorer
  1. Copy the JAR files from the CM API to the program workspace. Figure 9 shows the location of the ClearCase JAR files, and Figure 10 shows the location of the Rational common component JAR files.
Figure 9. ClearCase JAR files
Program Files\IBM\RationalSDLC\ClearCase\web\teamapi
Program Files\IBM\RationalSDLC\ClearCase\web\teamapi
Figure 10. Rational common components JAR files
Program Files\IBM\RationalSDLC\common
Program Files\IBM\RationalSDLC\common
  1. Import JAR files into the program. Figure 11 shows four steps to achieve this.
    1. Right-click on the project name and select Properties.
    2. On the left, navigate to the Java Build Path page.
    3. On the right, select the Libraries tab.
    4. Click the Add External JARs button and select the files that you want to add.
Figure 11. Import external JAR files
Properties for Update and JAR Selection dialog boxes
Properties for Update and JAR Selection dialog boxes
  1. Edit the Update.java. First, you should import packages into the program. Figure 12 shows the corresponding place in the program.
Figure 12. Import packages
Providers, resources, and properties packages
Providers, resources, and properties packages
  1. Second, given the CM API architecture, you know that you need to obtain the providers of the CM API before accessing any resource. Listing 3 gives the commands to obtain a provider.

The MyAuthCallback class, which implements the Callback interface in the javax.wvcm.ProviderFactory package, is used to get through the authentication. The CMServerUrl, login, and password parameters represent the URL of the CM Server, the login name, and the login password, respectively. All of them should be preassigned.

The format of CMServerUrl is as follows: http://ip:port/TeamWeb/services/Team, where “ip” is the IP address of the CM Server, and "port" is 12080 by default.

Listing 3. Get CM API provider
//new an instance of class MyAuthCallback
Callback callback = new MyAuthCallback(serverUrl, login, password);
//get provider with instance of callback
CcProvider provider = (CcProvider)
      Providerfactory.createProvider(CcProvider, .PROVIDER_CLASS, callback);
  1. Now that you have a provider, the next step is to get the view that was created during initialization. As you know, the root directory of the snapshot view is a common directory. Two special files (.copyarea.dat and .copyarea.db) that are under the directory make it the root directory of a view.

To get the resources of a view, you need to check whether these two files exist. If they exist, get the view. If not, return an error. Listing 4 shows the commands that you can use to get a view. Among the commands, comments start with a forward slash and two asterisks (“/**”). Replace them with commands to check for the two files.

The loc parameter is the path of the copy area of the snapshot view.

Listing 4. Get view
//new object of file with the root directory.
File file = new File(loc);
//the directory is a copy area for a certain snapshot view.
StpLocation stplocation = (StpLocation)
 provider.filePathLocation(StpLocation.Domain.CLEAR_CASE, file);
  1. After you get a view, you should collect the resources loaded in that view for update. Listing 5 shows the main commands to collect resources.
Listing 5. Collect resource
//get proxy for resource
ControllableResource res = getProxy(loc, provider);
//get properties for resource.
PropertyRequest prop = new PropertyRequest
(new PropertyRequestItem[] (ControllableResource.IS_VERSION_CONTROLLED));
Res = (ControllableResource) res.doReadProperties(prop);
//if the resource is under source control, add it into resource list. It will be updated
if ( res.getIsVersionControlled()) resourcelist.add(res);
  1. Now you come to the last step, which is to update the resources. Listing 6 shows the one command that you can use to do this. In this command, "view" is the view object that you created in Listing 4, and the resourcelist parameter contains all of the resources that you collected through the commands in Listing 5.
Listing 6. Update resource
//update resource
View.doUpdate(resourcelist, PropertyRequest.EMPTY);

So far, this article has discussed all of the actions needed to implement CI. In addition, you have set up the CI environment. The integration build will occur when it is scheduled in the configuration file. In the next section, you will examine the CI workflow.

CruiseControl workflow

You have set up and configured the environment. Now you will learn how this environment works.

Figure 13 depicts the overall workflow of CI with CruiseControl and ClearCase Remote Client.

Figure 13. CI workflow in CruiseControl
flow diagram with box elements in parallel columns
flow diagram with box elements in parallel columns

As Figure 13 shows, CruiseControl first reads the configuration file (config.xml) to get configuration information such as the following:

  • Edition of Ant
  • Location of source code
  • Style of source code
  • And so on

Then the process control is passed to Ant. It reads the build file first, and then runs a Java class that is used to update the source code. Next, it builds the source code, which is under ClearCase control. The last step is to send feedback.

There are several kinds of feedback methods, including Web, e-mail, and so on. For more information, see the CruiseControl Web site in the Resources section.

What you have learned

ClearCase Remote Client, a client for Rational ClearCase, contains many features and characteristics that support agile development, including:

  • Compacted navigator. All of the artifacts supported by ClearCase Remote Client are displayed in this navigator. Developers can easily create, edit, and delete elements from it.
  • Pending Changes view. Pending changes represent changes between parallel workspaces. The Pending Changes view lists all of the pending changes. In it, developers can conveniently review, deliver, and accept all of the changes.
  • Aggregated action. Batch processing is always needed, especially during initialization. ClearCase Remote Client supports several kinds of batch processing through aggregated action, including aggregated functionality to add to source control, check out, check in, and hijack. This feature reduces or eliminates a large number of steps, and saves a lot of time as a result.
  • Integration with ClearQuest. ClearCase focuses on source control, while ClearQuest is change request management software. Unified Change Management (UCM), which is a methodology that integrates ClearCase and ClearQuest, provides a solution for software development. ClearCase Remote Client supports UCM, which makes it a powerful tool that is lightweight at the same time.
  • Lightweight. ClearCase Remote Client requires very little resources, only a little space for installation files, just a few percent of processor time, and a bit of memory. All of these characteristics make it very easy for you to put ClearCase Remote Client to practical use.

All of these features and characteristics mean that ClearCase Remote Client supports agile development mode very well. CI is one of best practices of agile software development, and as a result of its support for frequent delivery from separate development workspaces to an integration workspace, it is becoming widely adopted.

Your development process will be much smoother if you use the same SCM software in both the development workspace and the integration workspace. This is because with the same software, no separate transactions are needed.

CI also requires that the controlled source code can be updated automatically. The CM API of Rational products makes it possible for ClearCase Remote Client to do this. The build tool can call a simple applicant program using the CM API. This application updates the source code in the snapshot view that was created in ClearCase Remote Client.

This article has shown you how you can use ClearCase Remote Client, along with CruiseControl and a build tool such as Ant, to support CI and agile development.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=417224
ArticleTitle=Continuous integration with IBM Rational ClearCase Remote Client
publish-date=08062009