| Prev | Next | ||
Software development policies and procedures differ widely from
organization to organization, but share a common goal: improving the
quality and time-to-market of the software under development. This
chapter discusses ClearCase's process and policy control mechanisms,
which are useful in activities that parallel the development process,
such as quality assurance and ECO (“engineering change order”)
administration.
ClearCase process control tools enable:
ClearCase process control tools enable:
- monitoring of the entire development process
- enforcement of development policies — controlling who can make changes; controlling how and where changes can be made
- automated communications, targeted as required at individual users, development groups, and managers
- organization and cross-referencing of all development data: source code, memos, design proposals, technical manuals, and so on
Reliable logging of information concerning development activities
plays a fundamental role in any process-control scheme. ClearCase
provides both automatic and user-controlled facilities for capturing
such information. It also provides simple commands for retrieving the
information, along with extensions for creating sophisticated reports (Figure 6-1).
When ClearCase client programs make changes to the development environment, they automatically store records in VOB databases. For example:
- When a user checks out a file element in order to edit it (and ultimately, create a new version of it), cleartool automatically stores a checkout version event
record in the element's VOB. This event record is accessible to all
users (and managers), through the “list checkouts” or “list history”
command.
- When a release engineer revises a source configuration by moving the version label R1.3_FINAL
from one version of an element to another, two event records are
automatically stored, and can be viewed with the “list history” command:
27-Oct.11:30 drp remove label "R1.3_FINAL" from version "f2@@/main/1" "Moved label "R1.3_FINAL" to version "/main/34"." 27-Oct.11:30 drp make label "R1.3_FINAL" on version "f2@@/main/2" "Moved label "R1.3_FINAL" from version "/main/33"."
- The ClearCase build utility, clearmake, automatically creates configuration records (CRs) that document software builds, as described in Chapter 5, “Building Software with ClearCase.”
The “show configuration record” command retrieves and lists a CR; it
has many filtering and selection options to enable precise information
retrieval. For example, a command can list the versions of all header
files used in the compilation of object module util.o in a particular build of executable hello.
-
Management of parallel development environments is made possible by the automatic recording of merges. Whenever a user integrates the work stored on a subbranch of an element back into the main branch (or performs a merge from the main branch “outward”), a merge arrow
is created in the element's VOB database, logically connecting the
merged versions. The presence (or absence) of merge arrows enables a
project leader to determine exactly what work is required to integrate
all of a project's branch-resident work back into the main line of
development.
The meta-data annotations introduced in Chapter 3, “ClearCase Meta-Data”
can be used to record process-control information in VOB databases.
Annotations can be attached to objects manually, with commands such as
“make attribute”. Alternatively, scripts that include such commands can
be invoked automatically when certain ClearCase operations take place.
For more on automatically-invoked procedures, see “Triggers”.
Meta-data annotations include:
Attributes can also be used to define groups of versions
involved in the same task. For example, ClearCase's integrations with
third-party bug-tracking systems place attributes on versions created
to fix bugs; the attribute's value indicates the associated bug report.
For a tighter implementation, individual versions of the
source module might be hyperlinked to the corresponding versions of the
functional specification, as they both evolve. Hyperlink inheritance
makes this a practical alternative to establishing links at the element
level: as one or both elements evolve, the newly-created versions
effectively “inherit” the closest hyperlink involving their direct
ancestors (Figure 6-2).
(Merge arrows, discussed in “Automatic Information Capture”, are implemented as version-to-version hyperlinks.)
Meta-data annotations include:
- Version labels
— Version labels record development milestones: baselevels, major
releases, and so on. In addition to playing a pivotal role in
organizing development activities, version labels make it easy to
answer fundamental process-control questions, such as “What version of
that file went into the last release?”.
- Attributes — Attributes (name/value
pairs) can be applied to elements, branches, and versions. Attributes
can record process-control metrics commonly applied to source code
modules, such as code quality and comment density.
- Hyperlinks — Objects can be connected with hyperlinks to implement requirements tracing.
For a relatively loose implementation, an element containing source
code might be hyperlinked to the element containing its functional
specification document (Figure 6-2).
(Merge arrows, discussed in “Automatic Information Capture”, are implemented as version-to-version hyperlinks.)
The preceding sections have mentioned ClearCase commands that
retrieve event records and configuration records information from VOB
databases. There is also a describe
command, which lists the version labels, attributes, and/or hyperlinks
attached to a particular object. For example, this command reveals
inherited hyperlinks of a particular version:
ClearCase also includes a query language, which locates objects using their meta-data. Following are some applications of the query facility to process control:
The query_language manual page provides a complete description of this facility.
% cleartool describe -ihlink DesignDoc hello.c@@/main/2 hello.c@@/main/2 Inherited hyperlinks: DesignDoc@366@/usr/hw /usr/hw/src/hello.c@@/main/1 -> /usr/hw/src/hello_dsn.doc@@/main/1 |
- A quality-assurance engineer uses a query on the CodeQuality attribute to determine which source versions fail to achieve a desired level.
- A development project leader determines which elements have already had their gopher_port version merged into the rel2_bugfix branch.
- A group leader generates a list of all versions created by user akp, or perhaps all versions created by akp in the last month.
Any process-control scheme requires an access control
component: limiting the use of individual data objects to particular
users or groups, and restricting the use of specific commands to
authorized individuals. This section discusses ClearCase mechanisms for
controlling users' access to file system data and to
configuration-management data structures (Figure 6-3). See “Triggers” for a discussion of the mechanisms that restrict command usage.
Access to file system objects is governed by a scheme that closely resembles the standard UNIX user/group/others
permissions model. Administrators can design development environments
that are both secure and flexible. For example, a VOB can be “opened
up” to users in several groups, without having to grant access rights
to the “entire world” (others).
All file system objects managed by ClearCase have access permissions, which can be listed with a standard operating system command:
The standard UNIX meanings of these permissions apply: the object is owned by a particular user, and belongs to a particular group;
three kinds of access (“read”, “write”, and “execute”) are either
granted or denied to the user/owner, to members of the object's group;
and to all others. An element, its branches, and all its versions have
the same access permissions.
ClearCase uses an object's permissions to control certain operations at the configuration management level — for example, to determine who can checkout an element.
All file system objects managed by ClearCase have access permissions, which can be listed with a standard operating system command:
% ls -l util.c -r--r--r-- 1 drp dvt 511 Feb 28 12:28 util.c |
ClearCase uses an object's permissions to control certain operations at the configuration management level — for example, to determine who can checkout an element.
Given a VOB's role as a component of the permanent data repository, access to physical VOB data storage is strictly controlled:
- Standard commands and programs cannot modify VOB storage. Users must enter ClearCase commands to modify VOBs.
- Physical storage for a VOB is protected against “back-door”
access. For example, all files in a VOB's storage pools belong to a
privileged user, the VOB owner, and are maintained in a read-only state.
Configuration management data structures are implemented by various objects stored in VOB databases. Whereas access permissions work primarily at the file-system level, locks
protect all kinds of objects at the VOB-database level — elements,
branches, branch types, even entire VOBs. A lock on an individual VOB
objects renders that object unchangeable by any user (except those
included on an optional exception list).
The effect of a lock can be small or large. For example, one lock might prevent any new development on a particular branch of a particular element; another lock might apply throughout a VOB, preventing creation of any new element of type compressed_file, or usage of the version label RLS_1.3.
Locks are useful for implementing temporary restrictions. For example, during an integration period, a lock on a single object — the main branch type — prevents all users who are not on the integration team from making any changes.
The effect of a lock can be small or large. For example, one lock might prevent any new development on a particular branch of a particular element; another lock might apply throughout a VOB, preventing creation of any new element of type compressed_file, or usage of the version label RLS_1.3.
Locks are useful for implementing temporary restrictions. For example, during an integration period, a lock on a single object — the main branch type — prevents all users who are not on the integration team from making any changes.
Automated user-defined procedures play an important role in process
control. Such procedures can increase the degree to which development
activities are guided, monitored, and/or controlled. For example,
automated procedures can:
Automated procedures are implemented by triggers,
which monitor ClearCase operations. (Access permissions and locks
“guard” objects; triggers “guard” operations.) Performing a certain
ClearCase-level operation on a certain object causes a trigger to fire,
executing one or more user-defined procedures. The context in which a
trigger fires can be defined either broadly or narrowly, in terms of
certain elements, meta-data, and ClearCase operations. For example, the
following are very broad and very narrow contexts, respectively:
The trigger procedure is typically a script. It can
perform any analysis or test, based on file system data, on meta-data,
on other factors (such as the user's identity), or on any combination
thereof.
- disallow an operation,
in order to enforce an organization's development policies (“all
checkins must have a comment of at least 50 characters”)
- notify users and/or managers of significant changes in the development environment
- supplement the information automatically captured by ClearCase commands with additional data, storing it as attributes
- ... whenever any element in a VOB is modified in any way
- ... when a particular attribute is used on a particular branch of a particular element
Perhaps the most important aspect of a trigger definition is whether
it is to fire before the ClearCase operation takes place, or after. Pre-operation triggers control ClearCase processing; post-operation triggers supplement it (Figure 6-4).
The mechanisms described in the preceding sections constitute a
powerful “toolset”, which administrators and project leaders can use to
implement their organization's policies. To illustrate how the
mechanisms work together, we present an example of implementing a
“state transition” process model.
A “final integration” task for a product release is to progress from the active state to the frozen state to the released state:
- During the initial active state, all users will be able to modify elements, but only on branches named rls2_integ.
- After an element enters the frozen state, only “priority 1” bugfixes will be permitted, and only users david and sakai will be permitted to make the fixes.
- When the task is finished, it will enter the released state. To record the final source configuration, the version label RLS2 will be applied to the entire source tree. To prevent possible confusion, all further work on rls2_integ branches will be forbidden, as will further activity involving the RLS2 label.
ClearCase triggers, attributes, and locks all play a role in defining the state transition model (Figure 6-5). The three states are modeled as the permitted values of a string-valued attribute, IntegStatus, which is applied to each rls2_integ branch created during the final integration task.
| Prev | Table of Contents | Next |
| Chapter 5. Building Software with ClearCase | Glossary |
No comments:
Post a Comment