Strategies for Deploying Configuring in Software Development Organizations

Management analyzed the development organization and determined ways to use Configuring to enhance the code management process. They then devised a transition strategy to deploy Configuring to the development groups.

Major goals for the transition strategy:

• Prototype the company's planned use of Configuring. Management wanted to try out the workspace hierarchy strategy they devised for a small group before deploying it to the entire organization.

• Gracefully incorporate Configuring into active development projects. Management wanted to impact current development schedules as little as possible.

• Pre-Configuring source file organization

• Configuring solution

• Transition plan that incrementally adopts Configuring into the development organization

Click for closeup.


 

This method of development made it difficult to coordinate the work of developers who shared common and interdependent files. Using SCCS in this manner provided only serial access to common files, one developer at a time -- this process created a productivity bottleneck. To get around the bottleneck, developers sometimes made copies of already checked-out files and copied them to their private work areas where they made changes. Changes were extremely difficult to track when the code was merged together.

The Configuring Solution

• A top-level release workspace. This workspace contains all of the product source files.

• An integration workspace for each functional group. Senior developers from each group work in these workspaces to integrate changes made by developers. The workspaces contain only the relevant sources for each group.

• A workspace for each developer or task. Development workspaces contain only the files that developers need to do their work.

Figure 18 shows the final hierarchy and the types of files contained at each level.

Click for closeup.


 

A major advantage of this workspace hierarchy is that it lends itself very well to the company's incremental transition plan. That plan is described in the next section.

The Transition Plan

The company decided on the following transition plan:

1. Initially, deploy the Configuring solution only in the CC group. This group was chosen for prototyping because:

• The CC group was the smallest of the three groups.

• The code produced by this group was used by both of the other projects. Therefore, the larger projects would be exposed to some Configuring concepts during the transition period.

2. Allow the VR and CR groups to work uninterrupted in their usual manner during the initial deployment.

3. After testing the solution, smoothly deploy the Configuring solution to the entire development organization as schedules permitted.

A workspace hierarchy is created: The existing project source hierarchy becomes the release workspace \xac . The source developed by the CC group is brought over to create an integration workspace \xad . Developer workspaces are created as required \xae .	Click for closeup.
Development continues: The VR and CR groups work directly in the Release workspace using their traditional methods. The CC group begins development in workspaces, using Configuring commands to transfer changes between the developer workspaces and the integration workspace, and between the integration workspace and the release workspace. Product releases are created from the Release workspace.	Click for closeup.
The VR and CR groups convert to Configuring workspaces when: The company decides that the Configuring process is working well in the CC group. VR and CR product development is at a convenient juncture (typically, just after a release).	Click for closeup.

• The only difference between a Configuring workspace and a standard directory is that the workspace contains a Codemgr_wsdata directory. Therefore, the CR and VR groups' use of the Release workspace as their source directory was totally transparent to them; for their purposes the Release workspace was just like their traditional project source directory.

• All developers in the CC group had their own workspaces. Periodically, changes made in those workspaces were integrated in the CC integration workspace and those changes were then integrated in the release workspace. Conversely, changes made by the CR and VR developers in the release workspace were brought down into the integration workspace, and then to the individual developers' workspaces. See the TW Topic Workspace Hierarchy Strategies for Software Development and Release on page 37" for more information about workspace hierarchies.