Using ALM without UCM

You can use the ALMBaseline and BTBuild record types without using UCM.

By using HCL VersionVault UCM the ALMBaseline and BTBuild records can automatically detect activities that are included in builds. However, you can also use the ALMBaseline and BTBuild record types to manage change and activities with systems that are not using UCM. The term, non-UCM refers to any system using a configuration or asset management solution other than UCM.

When you create a ALMBaseline record, you can use queries to identify the list of activities, and then manually add the activities to the ALMBaseline record.

Note: When adding an ALMActivity to an ALMBaseline record the ALMActivity ID must be valid or ALMBaseline is not updated with the activity added.

Creating baselines and builds

The ALMBaseline record is used to hold data on a baseline. In non-UCM this can be a Label placed on a repository. This label must be static for the life of the project. It should not be moved or be reapplied.

The ALMBaseline record's unique key is a combination of the BaselineName and PvobOrLocation fields. In UCM the PVOB holds the process information for a UCM project. In non-UCM the PvobOrLocation is the Location, which can be a component or project area, that makes the Label unique. For example, if you have two components, Gui and Core, that are built separately, but your nightly build labels are generic (such as NightlyBuild_2008Jan15) then you could create baseline records with the BaselineName and PvobOrLocation values: 
BaselineName=NightlyBuild_2008Jan15  Location=Gui 
BaselineName=NightlyBuild_2008Jan15  Location=Core

Given a baseline record, one or more builds may be derived from it. For example, if you build for three platforms, then for one baseline record you would need three build records.

Example

Libraries Ltd. is a software library producer. They create .jar files and release groupings of these files as archives. The company's change management (CM) system is file based. Each .jar file can be defined as a component. The archive that contains a grouping of .jar files can be defined as an offering. The component team .jar files are stored in directories (for example, Jar\Gui_01.jar, Jar\Gui_02.jar, ...) Component level Testers will test each .jar file at the component level. Components do not necessarily know what (product) offering they may be part of. The offerings are created by the release engineer (or Builder) who created the archive files that contain the components. Offerings are stored in directories (for example, Products\Sparkle_01 and Products\Dazzle_01). Product level Testers will test the archive files, and all the .jar files within it at the product level.

The overall work process includes these steps:
  • Create an ALMProject (for example, named nonUCM_GuiJar).
  • Create an ALMRequest and a ALMTask for the request.
  • Create an ALMActivity for the development work (for example, with Activity ID = ALM00000486).
  • Complete an ALMActivity. The Developer modifies the code and closes the Activity.
  • Create an ALMBaseline. Builder creates the jar file GUI_Jar_02.jar and creates a baseline record (GUI_Jar_02), adding in the Activities completed. The Builder can run a query (based on Developer Category and Release) and then click a Task in Result Set grid and view the Activities field. After the baseline is created, one or more builds can be built.
  • Create a BTBuild from the baseline. The Builder creates a new BTBuild, that references the appropriate ALMProject and ALMBaseline. The Activities tab on the BTBuild record shows all the activities that the ALMBaseline includes. The ALM tab on the BTBuild shows the connection to the ALM Baseline.
  • Test a build. The Tester can view an ALMTask and see what build the new functionality can be found in.

Creating a composite baseline means taking existing baselines and adding them to the Composed of Baselines field on a new baseline record. For example a product level baseline could include all the component level baselines.

In our example, the Composed of Baselines includes baseline GUI_Jar_02 from the component baseline. The Builder can then create a new BTBuild record off the new Dazzle_01 baseline. It is the same process as that used to create the build off the Gui component. The same ALMTask record reveals to the product level Tester in which build the new functionality can be found in.