| クリアケース | |
|---|---|
| 原作者 | アトリアソフトウェア |
| 開発者 | IBM |
| 初回リリース | 1992 (1992年) |
| 安定版リリース | 11.0.0.4 [ 1 ] / 2025年8月22日 ( 2025-08-22 ) |
| オペレーティング·システム | |
| プラットフォーム | |
| タイプ | ソフトウェア構成管理 |
| ライセンス | IBM EULA |
| Webサイト | www.ibm.com/products/devops-code-clearcase |
IBM DevOps Code ClearCase ( IBM Rational ClearCaseとも呼ばれる)は、ソースコードやその他のソフトウェア開発資産のソフトウェア構成管理(SCM)をサポートするコンピュータソフトウェアツールファミリーです。また、電子設計成果物の設計データ管理もサポートし、ハードウェアとソフトウェアの共同開発を可能にします。ClearCase はリビジョン管理機能を備えており、大規模および中規模企業における構成管理の基盤となり、数百人から数千人の開発者が関わるプロジェクトにも対応します。IBM によって開発されました。
ClearCaseは、UCM(Unified Change Management)とベースClearCaseの2つの構成管理モデルをサポートしています。UCMはすぐに使用できるモデルを提供し、ベースClearCaseは基本的なインフラストラクチャを提供します(UCMはベースClearCase上に構築されています)。どちらも、幅広いニーズに合わせてカスタマイズできます。
ClearCaseは、大容量のバイナリファイル、多数のファイル、そして大規模なリポジトリサイズに対応できます。ブランチとラベリングをサポートしています。ディレクトリをバージョン管理することで、リファクタリングされたファイルを正しくマージできます。また、トリガー、属性、ハイパーリンク、その他のメタデータを用いた広範なプロセスの自動化と適用もサポートしています。ClearCaseは、ワークスペースにどのバージョンのファイルとディレクトリを配置すべきかを透過的に決定し、ファイルアクセスとライフサイクルを調整する仮想ファイルシステムであるマルチバージョンファイルシステム(MVFS)を使用します。MVFSは、LAN展開では動的ビュー、LANまたはWAN展開では自動ビューに使用されます。[ 3 ] [ 4 ]
ClearCase は、信頼できるビルド監査機能も提供しています。この機能は、ビルドのコンテキストや、ビルド中に参照されたファイルの部品表(正確なバージョンを含む)など、各ビルド成果物のメタデータを生成します。このメタデータは SBOM(ソフトウェア部品表)の生成に使用でき、成果物のトレーサビリティが不可欠な規制環境において重要です。ClearCase には、信頼できるビルド監査メカニズムと統合された「make」実装が含まれており、タイムスタンプなしでビルドの正確性を確保し、ビュー(ワークスペース)間でビルド成果物を自動的に共有します。
ClearCaseはAtria Softwareによって開発され、1992年にUnix向けに初めてリリースされました[ 5 ]。その後Windows向けにもリリースされました。Atriaの開発者の中には、それ以前の類似システムであるApollo ComputerのDSEE ( Domain Software Engineering Environment)に携わっていた者もいました。 1989年にHewlett-PackardがApollo Computerを買収した後、それらの開発者はAtriaを設立するために去りました[ 6 ] [ 7 ] [ 8 ] 。Atriaはその後Pure Softwareと合併し、1996年にPureAtria [ 9 ]を設立しました。この会社は1997年にRational Softwareに買収され、Rational Softwareは2003年にIBMに買収されました[ 10 ]。IBMはClearCaseの開発と販売を継続しています。2016年9月、IBMはHCL Technologiesとの戦略的提携[ 11 ]を発表し、開発の迅速化を目指しました。
ClearCaseが使用するデータベースシステムは、RaimaのRDM Embeddedです。ClearCaseの用語では、個々のデータベースはVOB(Versioned Object Base )と呼ばれます。[ 12 ]このレイヤーでは、Raimaのツールを使用してメンテナンスが行われます。このレイヤーの周囲には、一連のインターフェースと付属ツールが使用され、物理データベースシステムを管理するための特別なデータベース管理者のスキルが求められます。[ 13 ]
最も重要なサービスはAtriaロケーションブローカーデーモン(ALBD)で、コンピュータ間のすべての(LAN)通信を管理します。バージョン7以降、サーバープラットフォームはWebsphere Application ServerとChange Management Server(CM Server)と呼ばれるサーバーアプリケーションを搭載し、HTTPプロトコル経由でClearCaseクライアントにサービスを提供しました。(バージョン7より前は、ユーザーがブラウザ経由でClearCaseにアクセスできるWebサービスがありました。)CM Serverはその後、ClearCase Remote Client Wide-Area Network Server(CCRC WAN Server)に置き換えられましたが、これも引き続きWebsphere Application Serverをベースとしています。
ClearCase の際立った特徴の一つは、マルチバージョン・ファイル・システム (MVFS) です。これは、動的ビューを介して VOB を仮想ファイル・システムとしてマウントし、一貫性のあるバージョンセットを選択して派生オブジェクトを生成する独自のネットワーク・ファイル・システムです。これはリポジトリとサンドボックスのモデルからの脱却であり、成果物の早期管理 (つまりチェックイン前) を可能にし、これらの一次構成項目の管理に限定されませんでした。
ClearCase は、リポジトリデータのコピーであるスナップショットビューもサポートしています。動的ビューとは異なり、スナップショットビューはローカル(OS 固有の)ファイルシステム上に保持され、ネットワークアクセスを必要としません。その代わりに、スナップショットビューは VOB データのコピーをユーザーのコンピュータ上にローカルに保存します。スナップショットビューはネットワークから切断されている間も使用でき、後で接続が再確立されたときに VOB と同期されます。この動作モードは、CVS(Concurrent Versions System)ソフトウェアの動作に似ています。
ClearCase ローカルクライアント (CCLC) は、動的ビューとスナップショットビューをサポートしています。ClearCase リモートクライアント (CCRC) は、自動ビューと Web ビューという類似のビュータイプをサポートしています。どちらもコピーベースですが、自動ビューは MVFS を使用して、共有可能なローカルの VOB オブジェクトプールをサポートします。
クライアントコンピュータから見ると、ClearCase ビューは単なるファイルシステムのように見えます。ClearCase ビューで作成された新しいファイルとディレクトリは、「ビュープライベート」と呼ばれます。これは、それらがビューに固有であり、バージョン管理されていないことを示します。この機能により、ビルドシステムはソースコードと同じファイルシステム構造で動作できるようになり、各開発者が互いに独立してビルドを実行できるようになります。ビュープライベートオブジェクトはいつでもソース管理に追加してバージョン管理オブジェクトにすることができ、他のユーザーが参照できるようになります。
開発者は通常、1つ以上のビューを自由に利用できます。開発者間でビューを共有することが実用的な場合もありますが、ブランチを共有する方がより一般的です。ブランチ階層は多くの場合便利です。開発プロジェクト全体で共通の開発ブランチを共有し、小規模なチームではサブブランチを共有し、各開発者が独自のプライベートブランチを持つことができます。ブランチの変更が十分に安定したと判断されたら、親ブランチにマージできます。
ClearCase の基本バージョンでは、各ビューは関連する構成仕様(一般的に構成仕様と呼ばれる)によって制御されます。これは、ビューに表示する要素バージョン(ファイルまたはディレクトリ)を指定する一連のルール(内部的にはテキストファイルに保存されますが、使用前にコンパイルされます)です。要素のどのバージョンを表示するかを決定するために、ClearCase は構成仕様を上から下まで行ごとに走査し、一致するものが見つかった時点で停止し、それ以降のルールは無視します。構成仕様は、「include」ステートメントを使用して他の構成仕様を参照することもできます。
UCM 管理モデルでは、構成仕様を手動で作成したり管理したりする必要はありません。構成仕様は ClearCase UCM 操作によって生成され、管理されます。
MVFSが提供するネットワークファイルシステムは、ビルド監査を可能にします。MVFSを使用するビュー内のビルドは、ビルドプロセス中に実行されるファイルI/O操作を監視および記録し、各イベントをそのトリガーとなったコマンドに関連付けることができます。これにより、ClearCaseはすべてのビルドに対して構成レコード(CR)と呼ばれる部品表を作成し、ソフトウェア構成管理目的、またはより大規模なアプリケーションライフサイクル管理プロセスの一部としてトレーサビリティを実現します。ビルド監査は、組み込みのmakeツール(omake、clearmake)などのコマンドラインツール、またはUnixのmake(1)などの別のビルドツールを呼び出すclearauditコマンドを使用して実行されます。
ファイル要素とディレクトリ要素のバージョンを保存するバージョン管理オブジェクト ベース (VOB) には、これらのオブジェクト タイプに関連付けられた派生オブジェクトとメタデータも保存されます。
ビルド監査の結果として生成される部品表アーティファクトは、構成レコードと呼ばれます。これには以下の内容が含まれます。
依存関係情報は、派生オブジェクトごとに表示できる構成レコードに保存されます。構成レコードを使用することで、ビルド時に読み込まれたすべてのファイルを表示する別のビューを作成できます。また、構成レコードを使用して、ビルド時に読み込まれたファイル(およびバージョン)にラベルを付与することもできます。
MVFSでは、ある動的ビューで作成された派生オブジェクトを、別の動的ビューで「全く同じ」派生オブジェクトを必要とする場合に自動的に「コピー」することができます。2つの派生オブジェクトは、同じ構成レコード(つまり部品表)を持つ場合、「全く同じ」とみなされます。共有可能な派生オブジェクトは、物理的にはVOBサーバーに存在し、それらを参照するビューには存在しません。この機能は派生オブジェクトのウィンクと呼ばれ、ビルドにはclearmakeまたはomakeツールを使用する必要があります。
ClearCase の動的ビューは、ネットワークインフラストラクチャが良好であっても、ローカルファイルシステムよりも遅くなります。ClearCase のmake代替によって有効化されるビルド回避により、後続ビルドを繰り返す場合は、より高速に実行される可能性があります。MVFS はファイルにアクセスするたびにサーバーへのアクセスが必要となるため、ファイルシステムのパフォーマンスはサーバーの容量に依存します。
当初、ClearCase は Unix および Windows 上でネイティブに動作するフル機能(「ファット」)クライアントのみをサポートしていました。バージョン 7 では、ClearCase Remote Client (CCRC) が導入されました。これは Eclipse ソフトウェアをベースとしており、Eclipse のフルパッケージ版、Eclipse 用プラグイン、そして Visual Studio などの他の環境向けに提供されています。
| クライアント | ネットワーク接続タイプ | ソース管理されたオブジェクトのリポジトリへの接続 | ビューの種類 | ユーザーインターフェース |
|---|---|---|---|---|
| ClearCase ローカル クライアント (CCLC) | LANのみ | バージョン管理されたオブジェクト ベース (VOB) への RPC 接続 | ダイナミック、スナップショット | ClearTeam Explorer (GUI)、cleartool (CLI) |
| ClearCase リモート クライアント (CCRC) | WANとLAN | CCRC WAN サーバー経由の VOB への http(s) 接続 | 自動、ウェブ | ClearTeam Explorer (GUI)、rcleartool (CLI) |
ClearQuestやRational Team Concertといった他のRational Software製品もClearCaseと統合されています。ClearCaseは、プラグインを通じてMicrosoft Visual Studio、Cadence Virtuoso、Eclipse IDEとも統合されています。
ClearCase MultiSiteを使用すると、異なる場所にいる開発者が、同じClearCaseバージョン管理オブジェクトベース(VOB)を使用できます。各場所(サイト)には、VOBのコピー(レプリカ)がそれぞれ存在します。任意のプロトコルによるデータ同期は、単方向または双方向で実行できます。同期パターンは、1対1(2つのレプリカ間でデータを交換)、リング(ラウンドロビン同期)、1対多(「ハブ」VOBからのレプリケーション)、または多対多(各レプリカが他のすべてのレプリカとデータを交換)のいずれかです。
DSEE(ドメイン・ソフトウェア・エンジニアリング環境)は、ClearCaseに採用された多くの概念を導入しました。Apolloドメイン・ファイルシステムは、ファイルアクセス中に特別なハンドラープログラムが介入することを可能にしました。DSEEはこの機能を利用して、特定のファイルが開かれた際に、バージョン管理されたコピーを目に見えない形で置き換えました。[ 14 ] バージョン管理仕様がユーザー環境に常駐することで、印刷や汎用テキストエディタでの閲覧といった日常的なアクセスも含め、バージョン管理されたファイルへのすべてのアクセスがリダイレクトされました。
DSEEは、すべてのソフトウェアモジュールとその依存関係を記述したファイルに大きく依存していました。このファイルは手動で生成する必要があり、大規模システムでの使用における大きな障害となっていました。しかし、一度生成すれば、DSEEはビルドを実行する最適な方法を計算できるようになり、以前に処理されたすべてのモジュールと、そのバージョン仕様がビルドの仕様と一致するモジュールを再利用できるようになりました。
DSEEは「バージョン仕様」も導入しました。これは「スレッド」と呼ばれていました。これは、ユーザー環境またはビルドに存在する可能性のあるバージョンのリストでした。大きな革新は、スレッド内でビルド署名とソフトウェアリリース署名が使用されるようになったことです。したがって、スレッド内の項目は次のようなものになります。
スレッドは各ファイルごとに上から下へと処理されました。開発者スレッドの場合は、先頭に「reserved」と表示され、その後にラベル付きバージョンが続く場合があります。既存リリースの修正の場合は、スレッドが「reserved」と表示され、その後にリリース署名が続きます。
Apolloドメインファイルシステムの不可視ファイルリダイレクトが利用できない場合、ClearCaseは後述のMVFS機能によって提供される仮想ファイルシステムを使用します。「スレッド」の概念は動的ビューに対応します。ビューにおける派生オブジェクトのサポートは、DSEEの概念に似ています。
V11.0.0(2024年3月)リリースおよび後続のフィックスパックリリース。[ 15 ]
V10.0.1(2023年10月)リリースとその後の修正パックリリース。[ 16 ]
V10.0.0(2022年12月)および後続の修正パックリリース。[ 17 ]
V9.1.0(2020年12月)および後続のフィックスパックリリース。[ 18 ]
V9.0.2(2020年1月)および後続のフィックスパックリリース。[ 19 ]
V9.0.1(2017年6月)および後続の修正パックリリース。[ 20 ]
V9.0 (2016 年 3 月) および後続の修正パック リリース。
V8.0.1(2013年6月)およびその後の修正パックリリース。[ 21 ]
V8.0 (2011 年 10 月) および後続の修正パック リリース。