ClearCase Build Concepts Rational ClearCase R supports makefile-based building of software systems and provides a software build environment closely resembling that of the make program. The ClearCase build tools, clearmake and omake, provide compatibility with other make variants, along with powerful enhancements: Build auditing, with automatic detection of source dependencies, including header file dependencies Automatic creation of permanent bill-of-materials documentation of the build process and its results Sophisticated build-avoidance algorithms to guarantee correct results when building in a parallel development environment Sharing of binaries among views, saving both time and disk storage Parallel building, applying the resources of multiple processors to builds of large software systems, is available within clearmake The clearaudit build tool provides build auditing and creation of bill-of-materials documentation. Both clearmake and omake incorporate the major ClearCase build-related features described in the following sections. In all other build-related documentation, the primary emphasis is on clearmake behavior. Overview of the ClearCase build scheme Developers perform builds, along with all other work related to ClearCase, in views.
|Published (Last):||17 August 2004|
|PDF File Size:||9.66 Mb|
|ePub File Size:||18.9 Mb|
|Price:||Free* [*Free Regsitration Required]|
Base ClearCase is the traditional method of ClearCase implementation; essentially it gives you a set of building blocks to define your own usage model. UCM, on the other hand, is a predefined but still customizable ClearCase usage model.
It is based on SCM best practices, and it hides to a certain degree the underlying metadata that is required to be implemented for a Base ClearCase process. However, UCM has a number of additional features above and beyond Base ClearCase that you can make use of in your automation efforts.
If you are new to ClearCase, I recommend looking at the UCM usage model first to see if it can work with your existing development process.
Chances are that it can. This section discusses the fundamental concepts of both Base ClearCase and UCM so that you will be familiar with them for later chapters. For more details on the different usage models, refer to the ClearCase product manuals [ClearCase03] or Bellagio and Milligan [Bellagio05], which has been updated with additional content for UCM. What Is a VOB? Essentially, a VOB is a database of element versions that maintains history and metadata about these file system elements as they evolve over time.
ClearCase manages all access to its VOBs. All users access the data in a VOB via a workspace called a view configured to look into it. A development project may encompass multiple VOBs. The VOBs from a build point of view contain all the source code that you will be building and releasing. Additionally, it is also possible to "stage" build-derived objects such as libraries and executables into a VOB if required.
What Is an Element? Any data that can be stored in a native file can be created as an element under ClearCase version control, such as source code, libraries, documents, and log files.
Each element is organized as a tree that iterates over a number of versions, as shown in Figure 2. Elements can be branched to support parallel development. ClearCase supports unlimited branching and corresponding merging to synchronize modifications carried out on different branches. Figure 2. Any particular version can also be labeled to indicate its importance or maturity.
Typically, a label is placed across a set of compatible element versions, with the label name given in uppercase, such as REL1. This book uses branches and labels to identify the set of files to build and the files that have already been built.
What Is a View? A ClearCase view is an individual workspace that is created to select a set of compatible file and directory versions from across one or more VOBs.
The view presents all the files and directories as a "native" file system. Typically a view is created per user and per task. For example, when you create a new file within your view, it is initially view-private: it exists only within that viewno other users can see the file.
Only when you add the file to source control do other users who are working on the same branch see the file. Similarly, when you check out a file, the checked-out copy resides only within your view.
Any changes you make to that file while it is checked out are visible to other users only when you check the file back in. The rules that define what versions of the files each of the views picks up is called a configuration specification described in more detail in the following section. ClearCase view mechanism The two types of views are snapshot and dynamic. A snapshot view is a traditional file system workspace. In other words, it contains physical instances of files and directories copied from the VOB.
A dynamic view looks and behaves like a physical copy, but it actually uses the ClearCase multiversion file system MVFS. MVFS allows dynamic views to access the server directly, rather like mounting a shared drive; very little content is downloaded to your local machine. In general, dynamic views are faster to create, faster to modify, and take up little disk space. Also, if you run builds within a dynamic view, ClearCase can audit what you are doing.
For example, if you are building a Java library, ClearCase can audit all the versions of the files that the view selects and that are built into that library. This can be very useful for impact assessment and traceability purposes. To bring a snapshot view in line with changes made by another user but on the same branch , you need to initiate an action to update the view, which may take several minutes.
With dynamic views, however, this process is transparent. One of the caveats with dynamic views involves build performance. Because each file system call goes through the MVFS, the time taken to build a Java library within a dynamic view might be significantly longer than the time it took to build the same library in a snapshot view.
This is particularly true on networks that have high latency. Obviously there is a need to look at the benefits of build time and performance with snapshot views versus the benefits of auditing and traceability with dynamic views. I will be using both types of views in the construction of our build environment. Continuous Integration and Dynamic Views If your build server is on the same subnet as your ClearCase server, or if you use fast network storage, it might be possible to reduce your "total build time" using dynamic views.
This is because total build time also includes workspace setup this setup is required for snapshot views but not for dynamic ones.
By its very nature, Continuous Integration is very sensitive to total build timethe faster you can build, the faster you can expose any potential problems.
Also, if there is an error, the compilation and unit testing would not be executed from beginning to end; however, the workspace setup phase would still need to be executed each time. I would therefore encourage you to run some test scenarios to see which approach is fastest in your own environment. What Is a Config Spec? As illustrated in Figure 2. This set of rules is called a configuration specification, or config spec for short. With each evaluation, parsing runs top to bottom. The evaluation stops as soon as a rule is encountered that successfully selects a version of the element in question.
In the preceding example, the first line looks to see if a particular element has been checked out to the current view. If it has, the view selects the checked-out copy. The third line is a bit more interesting. Here, rather than a branch, the starting point is a labelin this case, REL1, or release 1. The fourth line is included to match any new elements that are created, since they obviously have not had the label applied. Finally, the fifth line indicates a snapshot view.
If there is a large amount of data across your VOBs, you can reduce the scope of the load rules to copy only the files you need, thus reducing the load time and the disk space required on your local machine. VOB, views, branches, and element versions are all still visible behind the scenes. However, the fundamental tenet behind implementing UCM was to simplify the adoption of ClearCase by raising the level of abstraction and provide an out-of-the-box usage model. Rather than making you manually create your own branches and views and define your own config specs, UCM automates this process and introduces several high-level conceptsprojects, components, baselines, streams, and activities.
What Is a Project? When software development teams are organized into individual projects, each project may deliver a release of a product or some discrete and planned set of functionality. A UCM project is the physical realization of this concept.
Making the project a physical object of the SCM system lets you automate and manage a number of aspects of security and collaboration. A UCM project lets you define scope and development policies, such as what components or set of files and directories from the VOB repositories the project is allowed to change.
It also defines a common integration area where all the project changes are collected and integrated. Creating scripts around ClearCase command-line invocations is a typical way of automating manual activities. Command-line options are styled with a dash such as -long instead of a slash, and all commands are case-sensitive. Help exists for every cleartool command. What Are Components, Baselines, and Streams? I have already discussed the concept of a VOB as a version repository; a UCM component takes this idea one step further.
As with a VOB, a component allows you to organize files and directories into a particular structure representing part of an application or system architecture. However, a component is different in three ways. First, a VOB may contain many components. Third, each version of a component can be identified by a UCM baseline. An example is a baseline that has just been created as opposed to one that has gone through testing or into the live environment.
Once created, UCM baselines are immutable, so they can be used to define higher-level configurations. An entire system, for example, can be assembled from a set of such component baselines. If you have multiple components, one of the more powerful UCM features you can use is composite baselines.
Basically, a composite baseline allows you to create a baseline hierarchya single baseline that refers to a set of baselines, one from each component of your system or product. This makes it much easier to manage and recommend a baseline to developersyou have to remember only one baseline rather than many. To create a composite baseline, you create a dependency between component baselines. Also worthy of note is the concept of a UCM stream.
A stream is like a Base ClearCase branch in that it catalogs the series of element versions that change over time. However, unlike a branch, a stream captures additional informationin this case, the UCM component baselines that it is configured for and the UCM activities that are being worked on in it I discuss activities next. Streams also hide a lot of the complexity of configuration specifications, and users no longer need to edit and maintain them.
Each UCM project has a single integration stream where changes are delivered and usually has one or more development streams per developer. What Are Activities? Perhaps the most fundamental difference between Base ClearCase and UCM is that it is an activity-based change management model. This means that changes to files are grouped according to the reason for their change, such as making an enhancement, fixing a defect, or doing simple code refactoring.
A Review of ClearCase Concepts
The Call stack window shows the sequence of calls up to this point. Play with the Display menu to control what data is displayed. Expand window so that you can see the whole string. Click on the dog ear. This lets you see the previous value. Click again to see current value.
ClearCase Concepts Guide
This ensures orderly evolution of the repository and minimizes the likelihood of accidental damage or malicious destruction. The implementation, however, is modular: each source sub tree can be a separate versioned object base VOB. VOBs can be distributed throughout a local area network, accessed independently or linked into a single logical tree. To system administrators, modularity means flexibility; it facilitates load-balancing in the short term, and enables easy expansion of the data repository over the long term. Note: The repository can even be distributed over a wide-area network, or to sites that have no live data connection at all. The changes being made to a source file in a particular view are invisible to other views; software builds performed in a view do not disturb the work taking place in other views.
Introduction to the Rational ClearCase UCM tutorial
Since each VOB and its export view are located on the same host, three different export views are involved. The larger the block buffer cache, the less frequently it should be flushed. For a VOB or view with a registered tag, the output from lsvob -long and lsview -long includes: Moving a VOB Same Architecture This section presents a procedure for moving a VOB storage directory to another location, either on the same host or on another host with the same architecture. By contrast, no views are activated automatically at ClearCase startup; the user s on a client host must activate their view s with explicit commands.
Welcome to the SGI CASEVision Tutorium!