Here are 10 questions about ClearCase and related topics answered by
Howard Cohen, an
independent consultant specializing in
training services for
ClearCase through his company,
Timefold(tm).
ClearCase is a Software Configuration Management (SCM) system. That means it keeps track of which versions of which files were used for each release (even internal releases) and also which combinations were used in builds (including engineer builds, nightly and release builds). ClearCase also provides a rich and robust set of tools to allow a company to craft their engineering environment to their own requirements.
Your company would want ClearCase to help organize and address the increasingly complex problem of release and build management. You'd also want ClearCase to help you begin to replace your aging software engineering infrastructure. ClearCase would replace large portions of it with modern technology, allow much of the rest to run unchanged, and make it easier to implement high quality replacements for what remains and for new needs.
ClearCase contains a database, but it also contains many special applications which are tailored to facilitate the tasks engineers perform. SCM is a hard problem to solve well. The folks who created ClearCase actually previously implemented a very respectable, highly touted SCM system called DSEE, which ran on Apollo systems. ClearCase picks up many of the strong points of DSEE, but brings them to most of the modern development platforms, including NT. ClearCase isn't really an expert system; however, some of its tools contain the expert algorithms from highly experienced SCM System engineers.
You wouldn't want to have your own engineers try to implement an SCM system for your company, because it would be a huge undertaking. The effort is likely to produce a system with problems and limitations, and those will interfere with engineering from then on. Many policies will exist only to work around the limitations, and in the end, the system will limit the options of the engineering staff. In short, no money could possibly be saved by implementing your own SCM system, even if you already have engineers, a database, and time.
Yes, ClearCase is fundamentally different. ClearCase becomes a part of the operating system, so it has complete control over all access to files it manages. This is necessary both for security and so it can offer a transparent SCM service. You enter a directory structure which is managed by ClearCase, and you see files. Which versions of those files you see is based on a set of rules and a point in time (the current moment by default). You can back in time and you see different versions of files. You can use different rules and see different releases. All in the same directory structure, which itself is managed by the system. The end result is that many tools and techniques which worked in a previous SCM system (e.g. a in-house-built one) continue to work under ClearCase.
Another reason transparency is important is because almost any tool or program (e.g. web servers, desktop publishing systems, compilers, etc.) run inside of a ClearCase managed directory structure benefits from the rich SCM environment ClearCase offers. You don't have to teach each new tool about how your SCM system works. That means you can manage practically all your product-related files under the same system. That way, when you look at a historical release, you can easily get its documents, and other related files, knowing that they all went together at that time. Other SCM systems don't offer transparency through the operating system. They are applications, and as such cannot exert the kind of control nor be privy to the kind of information ClearCase has and needs to do the job well.
At first, the transition to ClearCase will cost time, just as any shift in infrastructure will. People will need to learn the new tools, and ClearCase must be set-up on various computers and workstations. Large installations must consider network issues to avoid unnecessary bottlenecks.
Once implemented the ClearCase offers many opportunities to save time. These include (at least):
If you use ClearCase exactly like your previous SCM system, you won't get any of these benefits of these opportunities. If you really just want something like SCCS, then SCCS is a better fit. But SCCS doesn't scale to the size and complexity of modern products, organizations, and development and release methodologies.
Using these capabilities in ClearCase can increase the complexity of the engineering environment, but ClearCase provides the tools to effectively cope with and manage that complexity. Frequently the business needs of a company force its engineering organization to undertake increasingly complex tasks. For example:
There are few if any simple answers to these problems that organizations are not already employing. To effectively cope, an organization needs methods and tools which don't buckle under increasing complexity. ClearCase is such a tool. Using techniques like branching and merging an organization using ClearCase can perform even the most complex codeline maneuvers.
Software engineering in a growing company is inherently increasingly complex. Saving time means not only getting the same job done in less time, but also minimizing the time required to cope with increasing complexity. Failure to cope with complexity successfully makes per-task time savings almost irrelevant.
So, yes, you can save time using ClearCase, and you can keep increasing complexity from eating up all your time. You can also lose time if you use or install ClearCase poorly. So, if you are serious about saving time even in the face of increasing complexity, you are ready for ClearCase.
Yes. First, ClearCase doesn't depend on copies of the repository. Instead, a branch for a file is created the first time someone in group checks the file out. From then on, everyone in the group works on the branch for that file. Files that were never checked out have no group branch. So, small parallel projects might branch only a few percent of the files, making them much easier to integrate with the work of other groups. This sparse branching model is much more efficient than copies of the repository.
ClearCase also provides excellent merge technology. ClearCase takes into account previous merges and the physical geneaology of files when merging. It can automate many aspects of merging, and the entire merge in some cases. Code conflicts must still be resolved by an engineer, as with any automated merge tools.
The combination make parallel development (work on branches) both practical and convenient.
That depends on many factors, but you can expect at least a few months. Many companies make the decision to buy ClearCase and then create aggressive schedules for its implementation. This doesn't work for a lot of reasons including:
Pushing too aggressively can also burn out your ClearCase experts, who are in tremendous demand in the industry right now, and are difficult to replace.
So, go slowly and carefully. Give your engineering organization time to make a reasonable transition. Improving software engineering infrastructure is a long-term commitment, and takes time to implement well. Short-term thinking can be disastrous in infrastructure, because the cost of rework can be quite large. Do it as well the first time as possible.
Yes, through the derived object sharing capability. ClearCase provides a make-compatible build system called ClearMake. ClearMake can determine that the derived object from one engineer or a nightly build depends upon all the same versions of files as another engineer is using. When that is the case, no compile is necessary, and the derived object is made available to both. It just "winks into" the workspace as though a compile had happened.
ClearCase takes into account the entire build command line, so objects from other architectures or with different compilation options are not shared.
ClearCase operates over your internal LAN, and in multiple subnets if you have them. There will be at least one computer whose failure shuts down ClearCase for some segment of users. Also, the failure of certain network equipment could make it seem that a critical host was down, having the same effect.
In general, the repository is remarkably robust. So, even in the face of an unstable computing and network environment, the mode of failure is generally lost access, not corrupted data.
Companies with crumbling computing and network environments have the most difficulty implementing ClearCase because it will make a bad situation worse.
To use ClearCase well generally requires reconsideration of existing policies and practices. This is a healthy step for any organization. It is better to pare back policies at first and (re)establish the needed ones over time. There is a risk that setting up too many policies in ClearCase right at the start can slow the system down and make it less robust. This can undermine confidence and enthusiasm in the system, both of which are helpful for a successful transition.
ClearCase can help a lot. First, you can manage your ISO-9000 documents under ClearCase. That provides both versioning of the files, but also affords you the opportunity to easily limit who can change the documents.
ClearCase provides a rich set of tools for automating or enforcing policies as needed. The ISO-9000 written policies can have a real-world, demonstrable implementation which ensures that they are followed.
ClearCase provides a flexible query tool for the production of reports which monitor compliance with your policies (for example, to look for check-ins which didn't receive a review).
Historically, the software industry has placed a low value on software engineering infrastructure. The tasks of creating and maintaining it were often added onto an already full workload of a senior or staff engineer with many other responsibilities.
As a result, few engineers ever had the opportunity to focus on infrastructure -- there was no career path in most companies. Then in about 1990, the industry began to wake up to the fact that quality, meeting schedules, and even engineer morale depended upon a sound software engineering infrastructure. Companies began to strive for SEI level 2, and later ISO-9000 compliance. To remain competitive they had to get more features out sooner and at a higher quality level than their competitors. This in the face of increasing complexity.
So, many companies realized that their engineering infrastructure needed a lot of work, and they began looking for suitable engineers. But there aren't many (yet) because there was no career path until recently for them. Since so many companies are interested in improving their infrastructure, and there aren't enough people who know how to do it, companies must often look within to find suitable engineers, or risk hiring someone with the expectation that they will grow into the job. I think more success is had with internal candidates because they already know the culture and policies of the company, which are vital to their ability to succeed in their new role. Such a position needs to be made attractive -- remember, the message engineers have received for a long time is: "do infrastructure work on your own time". It takes some clear messages from the very top of the company to turn that kind of attitude around and make an infrastructure position attractive enough for someone to change their career path.