Utilizzando ClearCase UCM i record ALMBaseline e BTBuild possono automaticamente rilevare le attività incluse nelle build. Tuttavia, è anche possibile utilizzare i tipi di record ALMBaseline e BTBuild per gestire modifiche e attività con sistemi che non utilizzano UCM. Il termine non UCM si riferisce ai sistemi che utilizzano una soluzione di gestione degli asset o della configurazione diversa da UCM.
Quando si crea un record ALMBaseline, è possibile utilizzare le query per identificare l'elenco di attività e, quindi, manualmente aggiungere le attività al record ALMBaseline.
Il record ALMBaseline viene utilizzato per contenere i dati su una baseline. In un ambiente non UCM ciò può essere un'etichetta collocata su un repository. Questa etichetta deve rimanere statica per tutta la durata della vita del progetto. Non dovrebbe essere spostata o riapplicata.
BaselineName=NightlyBuild_2008Jan15 Location=Gui BaselineName=NightlyBuild_2008Jan15 Location=Core
Fornito un record baseline, da esso possono derivare una o più build. Ad esempio, se si esegue la build per tre piattaforme, per un solo record baseline sono necessari tre record build.
Libraries Ltd. è un produttore di librerie di software. L'azienda crea dei file .jar e dei raggruppamenti di release di tali file come archivi. Il sistema di gestione della modifica dell'azienda si basa sui file. Ogni file .jar può essere definito come un componente. L'archivio che contiene un raggruppamento di file .jar può essere definito come una offerta. I file .jar del team del componente vengono memorizzati in directory (ad esempio, Jar\Gui_01.jar, Jar\Gui_02.jar, ...) I tester al livello di componente eseguono il test di ciascun file .jar al livello del componente. I componenti non conoscono necessariamente di quale offerta (prodotto) fanno parte. Le offerte vengono create dal tecnico di release (o Builder) che crea i file archivio che contengono i componenti. Le offerte vengono memorizzate in directory (ad esempio, Products\Sparkle_01 e Products\Dazzle_01). I tester al livello di prodotto eseguono il test dei file archivio e di tutti i file .jar al loro interno al livello del prodotto.
Creare una baseline composta significa prendere delle baseline esistenti e aggiungerle al campo Composed of Baselines su un nuovo record baseline. Ad esempio, una baseline al livello di prodotto può includere tutte le baseline al livello di componente.
Nell'esempio, il campo Composed of Baselines include la baseline GUI_Jar_02 proveniente dalla baseline componente. Il Builder può, quindi, creare un nuovo record BTBuild dalla nuova baseline Dazzle_01. Si tratta dello stesso processo utilizzato per creare la build dal componente Gui. Lo stesso record ALMTask rivela al tester al livello di prodotto, in quale build è possibile trovare la nuova funzionalità.