Durch Verwendung von ClearCase UCM können die ALMBaseline- und BTBuild-Datensätze automatisch Aktivitäten ermitteln, die in Builds enthalten sind. Sie können die Satztypen "ALMBaseline" und "BTBuild" jedoch auch für das Änderungsmanagement und für Aktivitäten mit Nicht-UCM-Systemen verwenden. Der Begriff Nicht-UCM bezieht sich auf alle Systeme, die eine andere Konfiguration oder Asset-Managementlösung als UCM verwenden.
Wenn Sie einen ALMBaseline-Datensatz erstellen, können Sie Abfragen verwenden, um die Liste der Aktivitäten anzugeben, und dann die Aktivitäten manuell dem ALMBaseline-Datensatz hinzufügen.
Der ALMBaseline-Datensatz wird verwendet, um Daten in einer Referenzkonfiguration zu speichern. In Nicht-UCM-Systemen kann das ein Kennsatz sein, der in einem Repository platziert wird. Dieser Kennsatz muss für die gesamte Lebensdauer des Projekts statisch bleiben. Er darf nicht versetzt oder erneut angewendet werden.
BaselineName=NightlyBuild_2008Jan15 Location=Gui BaselineName=NightlyBuild_2008Jan15 Location=Core
Wenn Sie einen Datensatz für eine Referenzkonfiguration haben, können ein oder mehrere Builds von ihm abgeleitet werden. Wenn Sie z. B. einen Build für drei Plattformen erstellen, bräuchten Sie für einen Datensatz für Referenzkonfiguration drei Build-Datensätze.
Libraries Ltd. ist ein Produzent von Softwarebibliotheken. Das Unternehmen erstellt JAR-Dateien und gibt gruppierte Dateien dieses Typs als Archive heraus. Das CM-System (Change Management) ist dateibasiert. Jede JAR-Datei kann als Komponente definiert werden. Das Archiv, das eine Gruppierung von JAR-Dateien enthält, kann als Angebot definiert werden. Die JAR-Dateien des Teams "Komponente" werden in Verzeichnissen gespeichert (z. B. "Jar\Gui_01.jar", "Jar\Gui_02.jar", ...). Tester, die für die Komponentenebene zuständig sind, testen jede JAR-Datei auf Komponentenebene. Es steht nicht notwendigerweise fest, welchem (Produkt-)Angebot die Komponenten zugeordnet werden. Die Angebote werden vom Releaseentwickler (oder Build-Ersteller), der die Archivdateien mit den Komponenten erstellt hat, erstellt. Angebote werden in Verzeichnissen gespeichert (z. B. in "Products\Sparkle_01" und "Products\Dazzle_01"). Tester, die für die Produktebene zuständig sind, testen die Archivdateien und alle enthaltenen JAR-Dateien auf Produktebene.
Beim Erstellen einer kombinierten Referenzkonfiguration werden vorhandene Referenzkonfigurationen zum Feld Composed of Baselines in einem neuen Datensatz für Referenzkonfiguration hinzugefügt. Eine Referenzkonfiguration auf Produktebene kann beispielsweise alle Referenzkonfigurationen auf Komponentenebene enthalten.
Im vorliegenden Beispiel enthält das Feld Composed of Baselines den Namen "GUI_Jar_02" der Referenzkonfiguration der Komponente. Der Build-Ersteller kann dann einen neuen BTBuild-Datensatz aus der neuen Referenzkonfiguration "Dazzle_01" erstellen. Dabei handelt es sich um denselben Prozess wie bei der Erstellung des Builds aus der Komponente "Gui". Derselbe ALMTask-Datensatz gibt dem für die Produktebene zuständigen Tester Aufschluss darüber, in welchem Build die neue Funktionalität gefunden werden kann.