You can use primary non-key groups as a technique to allow integration and testing of a software application. The technique is useful where integration work can have far-reaching and undesirable effects, for example, when a global change to an application affects the majority of developers. The technique is also useful when schedule or other pressures are such that you must perform high-risk integration of software. SCLM does not allow you to promote from a primary non-key group.

In a normal SCLM scenario, you promote code from individual development libraries to a common integration group before performing integration testing. However, you can generate an alternate project definition that deviates from the default project definition. The alternate project definition defines an intermediate non-key group for integrating subsets of development groups. Define the non-key group so that only key groups promote into the non-key group. Developers authorized to this intermediate group can then promote code to it for unit and function testing. Testing takes place in this group before promotion to the normal integration group. Because being at a non-key group does not cause members to be purged from a key group during a promote, no members are removed from the default project definition. In this way, you avoid potential integrity problems.

Using this technique, the activities of small groups of integrators do not affect the normal hierarchy until their testing is complete. By switching to the alternate project definition, developers can easily test their integration by promoting to the primary non-key group. When promoting to a non-key group, code still exists in the normal hierarchy in the development libraries. SCLM promotion from the development libraries, using the default project definition, would then incorporate the code into the normal integration group. New code can go through an accurate configuration test before being applied to the normal hierarchy. Code developed using this scenario is potentially more complete and accurate than code developed in a normal scenario.

Use Figure 1 and Figure 2 to compare a default hierarchy structure with an alternate hierarchy structure. Figure 1 shows a default hierarchy structure for a project. You can perform all normal development activities within the default hierarchy structure.

Figure 1. Default (Primary) Project Hierarchy Structure

Figure 2 shows an alternate hierarchy structure with a primary non-key integration group for the project shown in Figure 1.

Figure 2. Alternate Project Hierarchy Structure with Primary Non-key Integration Group

In the example, the developers (USER1, USER2, USER3) can use the alternate project definition to promote code into the primary non-key group. You cannot promote up from the primary non-key group, but you can draw down from it.

Promotion to a non-key primary group does not cause deletion of the components from the respective development libraries. Building in the primary non-key group allows the developers to integrate and test pieces of code still under development. Code that is then complete can be promoted through the default project definition from the development libraries into the normal integration group. The promotion to the normal integration libraries causes the components to be deleted from the respective development libraries, but not from the primary non-key group. Deletion from the primary non-key group must be done manually using the SCLM Library Utility, the Delete from Group Utility or through SCLM services, such as DELGROUP.