ClearCase® UCM を使用すると、ALMBaseline と BTBuild レコードは、ビルドに含まれるアクティビティを自動的に検出できます。ただし、UCM を使用しないシステムで、ALMBaseline と BTBuild レコード タイプを使用して、変更とアクティビティを管理することもできます。UCM 以外 という用語は、UCM 以外の構成やアセット管理ソリューションを使用するシステムのことを表します。
ALMBaseline レコードを作成する際、クエリーを使用してアクティビティのリストを特定してから、そのアクティビティを手動で ALMBaseline レコードに追加できます。
ALMBaseline レコードは、ベースラインにデータを保持するために使用されます。UCM 以外では、これはリポジトリに配置されるラベルにできます。このラベルは、プロジェクトの存続中は静的である必要があります。移動したり、再適用したりしないでください。
BaselineName=NightlyBuild_2008Jan15 Location=Gui BaselineName=NightlyBuild_2008Jan15 Location=Core
ベースライン レコードが指定されると、1 つ以上のビルドがそこから派生します。たとえば、3 つのプラットフォーム用にビルドする場合は、1 つのベースライン レコードに対して 3 つのビルド レコードが必要になります。
Libraries Ltd. は、ソフトウェア ライブラリ製作者です。 .jar ファイルを作成し、それらのファイルをグループ化したものをアーカイブとしてリリースします。会社の変更管理 (CM) システムは、ファイル ベースです。各 .jar ファイルは、コンポーネント として定義できます。.jar ファイルをグループ化したものを含むアーカイブは、オファリング として定義できます。コンポーネント チームの .jar ファイルは、ディレクトリに保管されます (たとえば、Jar¥Gui_01.jar、Jar¥Gui_02.jar、...)。 コンポーネント レベルのテスト担当者は、各 .jar ファイルをコンポーネント レベルでテストします。どの (製品) オファリングの一部であるかについて、コンポーネントが必ずしも認識している必要はありません。オファリングは、コンポーネントを含むアーカイブ ファイルを作成したリリース エンジニア (またはビルダー) によって作成されます。オファリングは、ディレクトリに保管されます (たとえば、Products¥Sparkle_01 や Products¥Dazzle_01)。製品レベルのテスト担当者は、アーカイブ ファイルと、アーカイブ ファイル内のすべての .jar ファイルを、製品レベルでテストします。
複合ベースラインの作成とは、既存のベースラインを取り出して、新規ベースライン レコードの [ベースラインで構成] フィールドに追加することです。たとえば、製品レベルのベースラインには、すべてのコンポーネント レベルのベースラインを含めることができます。
この例では、[ベースラインで構成] には、コンポーネント ベースラインから GUI_Jar_02 のベースラインが組み込まれます。次にビルダーは、新規の Dazzle_01 ベースラインから、新規の BTBuild レコードを作成できます。これは、Gui コンポーネントからビルドを作成するために使用するプロセスと同じプロセスです。同じ ALMTask レコードが、製品レベルのテスト担当者に、新規機能を検出できるビルドを示します。