IBM DevOps Code ClearCase
IBM DevOps Code ClearCase is a family of computer software tools that supports software configuration management of source code and other software development assets. It also supports design-data management of electronic design artifacts, thus enabling hardware and software co-development. ClearCase includes revision control and forms the basis for configuration management at large and medium-sized businesses, accommodating projects with hundreds or thousands of developers. It is developed by IBM.
ClearCase supports two configuration management models: UCM and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure. Both can be customized to support a wide variety of needs.
ClearCase can accommodate large binary files, a large number of files, and large repository sizes. It supports branching and labeling. It enables the correct merging of refactored files by versioning directories. It also supports extensive process automation and enforcement using triggers, attributes, hyperlinks, and other metadata. It uses the MultiVersion File System, which is a virtual file system that transparently determines which versions of files and directories should be in the workspace and orchestrates file access and lifecycle. The MVFS is used in LAN deployments for dynamic views and in LAN or WAN deployments for automatic views.
ClearCase also provides authoritative build auditing, which generates metadata for each build artifact, including the context of the build and a bill of materials of files referenced during the build. This metadata can be used for generating SBOMs and is important in regulated environments where artifact traceability is essential. ClearCase includes an implementation of 'make' that integrates with the authoritative build auditing mechanism to ensure build correctness without timestamps and automatic sharing of build artifacts across views.
History
ClearCase was developed by Atria Software and first released in 1992 on Unix and later on Windows. Some of the Atria developers had worked on an earlier, similar system: DSEE from Apollo Computer. After Hewlett-Packard bought Apollo Computer in 1989, those developers left to form Atria. Atria later merged with Pure Software to form PureAtria in 1996. That firm was acquired by Rational Software in 1997, which was purchased by IBM in 2003. IBM continues to develop and market ClearCase. In September 2016, IBM announced a strategic partnership with HCL Technologies that will allow for accelerated development.Infrastructure
The database system that ClearCase uses is RDM Embedded from Raima. In ClearCase terminology, an individual database is called a VOB. On this layer, maintenance takes place using Raima tooling. Around this layer, a set of interfaces with accompanying tools are used to manage the physical database system, which requires specific Database administrator skills.The most important service is the Atria location Broker Daemon, which manages all communication between computers. Beginning with version 7, the server platform runs Websphere Application Server with a server application called the Change Management Server, which served ClearCase clients via the HTTP Protocol. CM server has since been replaced by the ClearCase Remote Client Wide-Area Network Server, which continues to be based on Websphere Application Server.
Views
A distinguishing feature of ClearCase is the MultiVersion File System, a proprietary networked filesystem which can mount VOBs as a virtual file system through a dynamic view, selecting a consistent set of versions and enabling the production of derived objects. This was a departure from the repository-and-sandbox model because it enabled the early management of artifacts and was not limited to the management of these first-order configuration items.ClearCase also supports snapshot views, which are copies of repository data. As opposed to dynamic views, snapshot views are maintained on a local file system and do not require network access. Instead, a snapshot view stores a copy of the VOB data locally on the user's computer. Snapshot views can be used while disconnected from the network and later synchronized with the VOB when a connection is reestablished. This mode of operation is similar to that of CVS software.
The dynamic and snapshot view types are supported by the ClearCase local client. The ClearCase remote client supports analogous view types: the automatic view and the web view. Both are copy-based, but the automatic view uses the MVFS to support local, shareable pools of VOB objects.
From the perspective of the client computer, a ClearCase view appears to be just another file system. New files and directories created in a ClearCase view are referred as "view-private" to indicate that they are specific to the view and not version-controlled. This feature allows build systems to operate on the same file system structure as the source code and ensures that each developer can build independently of one other. At any time, a view-private object can be added to source control and become a versioned object, rendering it visible to other users.
Developers typically have one or more views at their disposal. It is sometimes practical to share views between developers, but sharing branches is the more common practice. A branch hierarchy is often useful: an entire development project can share a common development branch, while a smaller team can share a sub-branch, with each developer having his or her own private branch. Whenever a change on a branch is deemed stable enough, it can be merged to the parent branch.
The configuration specification
Under base ClearCase, each view is controlled by its associated configuration specification, commonly referred to as a config spec. This is a collection of rules that specifies what element versions are to be displayed in a view. To determine which version, if any, of an element should be visible, ClearCase traverses the configuration specification line-by-line from top to bottom, stopping when a match is found and ignoring any subsequent rules. A configuration specification can also reference other configuration specifications by means of an 'include' statement.In the UCM management model, config specs do not need to be created or maintained manually: they are generated and maintained by ClearCase UCM operations.
Builds
The networked filesystem provided by MVFS allows for build auditing. Builds in views that use the MVFS can monitor and record file I/O operations performed during the build process and associate each such event with the command that triggered it. This allows ClearCase to produce a bill-of-materials which it calls a Configuration Record for all builds and enable traceability for either software configuration management purposes or as part of a larger application lifecycle management process. Build auditing is performed with command-line tools such as a built-in make tools or by using the clearaudit command, which can invoke another build tool, such as Unix make.The Versioned Object Base that stores versions of file elements and directory elements also stores derived objects and metadata associated with these object types.
The bill-of-materials artifact produced as the result of build auditing is known as the Configuration Record. It contains:
- The build procedure: The method that invoked the build.
- Inputs: All files that were used for a particular build.
- Outputs: All derived object files produced as a result of the build.
The MVFS allows derived objects that were built in one dynamic view to be automatically "copied" to another dynamic view that requires "exactly the same" derived object. Two derived objects are deemed to be "exactly same" if they have the same configuration record. The shareable derived objects are physically present in the VOB server, not in the views that reference them. This feature is called winking in derived objects and requires that the clearmake or omake tool is used for builds.
ClearCase dynamic views are slower than local filesystems, even with a good network infrastructure. Repeated subsequent builds may run faster, due to build avoidance that is enabled by ClearCase's make substitute. Because MVFS requires server access every time a file is accessed, the performance of the file system depends on server capacity.
Client types
Originally, ClearCase supported only full clients running native on Unix and Windows. In version 7, the ClearCase Remote Client was introduced. It is based on Eclipse software and supplied in both fully packaged Eclipse versions, as a plugin-in for Eclipse, and for other environments such as Visual Studio.| Client | Network connection type | Connection to repository of source-controlled objects | View types | User interfaces |
| ClearCase local client | LAN only | RPC connection to a versioned object base | Dynamic, snapshot | ClearTeam Explorer, cleartool |
| ClearCase remote client | WAN and LAN | http connection to a VOB through a CCRC WAN server | Automatic, web | ClearTeam Explorer, rcleartool |