WorkShop Teamware: Solutions Guide: - Workspace Hierarchy Strategies for Software Development and Release

# Workspace Hierarchy Strategies for Software Development and Release |

The way you organize the Configuring tool workspaces into development hierarchies affects how software changes move through your development groups and how you manage software releases.

This topic discusses workspace hierarchy strategies that have been developed at a large software development site that uses Configuring.

This discussion is intended to present you with ideas and concepts that you can adapt to your own unique development environment. Perhaps the most significant underlying concept presented in this discussion is that Configuring workspace hierarchies are flexible. Configuring enables you easily reconfigure hierarchies as your project, organization, and experience with Configuring evolve.

## Scenario

A company that produces software to control assembly line processes recently purchased Configuring to help it manage its large software development process. This company markets two products -- one controls large, heavy industrial processes and another controls electronics assembly lines. The industrial product employs approximately 100 developers and the electronics product employs about 75 developers.

After analyzing their development and release processes, company management recognized that their primary goals for using Configuring were to:

- Increase developer access to software changes. As changes are made to various parts of the product, make them quickly available to developers whose work is affected by those changes.

- Maximize developer access to integration areas by keeping software changes accessible to developers during the integration process. Integration consists of merging the changes made by individual developers and then, later, integrating those changes with changes made by other groups of developers.

- Increase the stability of integration and release areas.

- Facilitate concurrent development of multiple software releases.

- Move features between releases.

- Manage unanticipated releases.

The company realized that a key to accomplishing these goals was to effectively organize its workspace hierarchies.

## Implementation

The following sections describe the workspace hierarchy strategies developed by company management that enabled them to meet their goals.

### Workspace Hierarchy Levels

The company decided that to best organize both development groups (the Industrial Group and the Electronics Group), the development workspace hierarchies must be at least three levels deep. These levels are:

- Development
- Integration
- Release

> Note - Your workspace hierarchies may require fewer levels or more levels than this company decided was optimal for it. If your project consists of a very large number of developers, you can add a second sub-integration level in order to reduce the number of developers that put back work to each integration workspace. If, on the other hand your project is not large, you can omit the integration level entirely and have developers put back work directly to the release workspace. The principles described in this section apply in either case.

    Click for closeup.

#### Figure 1 Workspace Hierarchy Levels

#### Development Level

This is the level in which the code development work is done. Generally, each developer has her own workspace. Note that a developer who works on more than one distinct task might have more than one workspace.

In a typical development cycle, the developer:

- Brings over changes from the integration level
- Merges the changes into her own work
- Makes additional changes
- Tests the changes
- Puts the merged changes back to the integration workspace

Development workspaces generally contain only the files required for the developer to build and test her work.

#### Integration Level

Integration workspaces are used to combine the work of a number of developers. Generally, integration workspaces are allocated based on functionality, for example the group responsible for a large library and the group responsible for product's I/O drivers are assigned their own integration workspaces. Developers working in these functional areas share their changes by putting their changes back to their integration workspace and by bringing over changes made by other developers from these workspaces.

Integration workspaces generally contain only the files required to build and test a given portion of the product.

#### Release Level

The release level is comprised of a single workspace at the top of the hierarchy. After work done by developers in functional groups is integrated in the integration workspaces, it is put back to this workspace for final product release integration, testing, and dissemination to the other integration workspaces. Each release is generated from child workspaces of the release workspace that are created specially for this purpose.

Release workspaces contain all the files that comprise the product.

### Optimizing Integration

Company management decided that one of the most crucial steps in the development process is the integration of developers' work in both the integration workspaces and in the release workspace. The strategies discussed in this section maintain the consistency and availability of integration workspaces.

If integrators work directly in integration workspaces, the workspaces must be locked against putback and bringover transactions from developers in order to ensure consistency. Locking integration workspaces interrupts the development process by preventing developers from exchanging code.

Likewise, when the work from integration workspaces is integrated into a release workspace, the release workspace also goes through a period of instability. During the time it takes to incorporate changes, work cannot be putback to, or brought down from the release workspace.

The development groups arrived at two strategies to address these issues. The two strategies are very similar, but they differ slightly in the way integration is managed. Both strategies mitigate the disruption caused by the integration process.

The first strategy was adopted by the Electronics Group. Their product is highly interdependent -- the entire product must be integrated as a whole. The second strategy was adopted by the Industrial Group. Their product is more modular -- the different functional areas can be integrated separately.

#### Strategy 1

Because the Electronics Group's product is highly interdependent and must be integrated as a whole, this strategy utilizes a main integration workspace in which the entire electronics product is integrated.

Integration does not actually take place in the individual integration workspaces. Instead the code is brought over from the individual integration workspaces to the main integration workspace where the work is integrated, tested, and then put back to the release workspace. Figure 2 illustrates this process.

    Click for closeup.

#### Figure 2 Using a Main Integration Workspace (Strategy 1)

The following steps outline how changes are integrated and moved into the Release workspace.

  1. A Main Integration workspace is created.

  2. At specified development milestones, the Main Integration workspace is reparented (in turn) to each Integration workspace and all changes are brought over into it (A).

  3. The changes are integrated, tested, and stabilized entirely in the Main Integration workspace.

  4. After the integration is complete and stable, the contents are put back to the Release workspace where it becomes available to the Integration workspaces, and ultimately to the developers (B).1

This strategy accomplishes the following goals:

- It isolates the disruption caused by the integration process from the main development environment.

  By using the bringover transaction to transfer changes from the integration workspaces into the Main Integration workspace, all conflicts are isolated in the Main Integration workspace. If the putback transaction is used to transfer changes directly from integration workspaces to the Release workspace, conflicts are resolved directly in the integration workspaces.

- Developers can continue to put back and bring over changes without disrupting the integration process.

- Changes are not introduced to the Release workspace until they have been stabilized in the Main Integration workspace.

#### Strategy 2

The Industrial Group employed a variation of Strategy 1. Their source base is organized so that sub-components of the product (contained in integration workspaces) can be integrated separately or in groups. An advantage of this strategy is that changes made by developers can be disseminated throughout the hierarchy as they become ready, rather than waiting for the entire project to be ready as is the case in Strategy 1. Final product integration is postponed until all changes are present in the release workspace.

Figure 3 describes Strategy 2.

    Click for closeup.

#### Figure 3 Using Integration Workspace Clones (Strategy 2)

### Peer-to-Peer Updates

After the company began using Configuring, some developers discovered that it was sometimes helpful to reparent and use the bringover transaction to directly update each other's workspaces. This is shown in Figure 4.

    Click for closeup.

#### Figure 4 Peer-to-Peer Updates Using the Bringover Transaction

This peer-to-peer update technique was found to be useful when two or three developers are working closely on a specific part of a project. They are typically part of an integration group that contains other developers who are working in other areas. It is sometimes efficient and convenient for closely coupled developers to share their work directly with each other and not through the normal workspace hierarchy.

Development groups have found this strategy to have these advantages:

- Developers exchange information efficiently and quickly.

- Developers can share unstable, experimental code without going through the common integration workspace where it can inadvertently be brought over by other developers.

They have also found that the strategy can have these disadvantages:

- When it is time for the developers to put their code back to the integration workspace, they put back changes made by the other developer along with their own changes. This requires developers to merge code they haven't written.

- Code that should be shared with other developers is sometimes not available to them as quickly as it would be if the updates had been made through the common integration workspace.

These co-developers use the bringover transaction to exchange work directly between their workspaces. This is best accomplished by reparenting "on-the-fly" as part of the bringover transaction (specify an alternate parent in the Transactions Window or use the `-p` option on the command-line).

> Note - Generally, the putback transaction is not used in this manner because it is best that a developer not change the contents of another developer's workspace.

### Concurrent Development

The company often finds itself in the position of developing multiple product releases concurrently. For example, development of Release 2 of the industrial product began well before development of Release 1 was complete.

The company employs a couple of strategies to assist it with concurrent development. The major goals of these strategies are to:

- Ensure that successive releases are based on the same consistent set of sources

- Ensure that all features developed for Release 1 are also included in Release 2

- Facilitate the porting of features to Release 2 that were intended for Release 1 but were not completed in time

The Cascade Model was found most effective when the source bases for Release 1 and Release 2 are closely related. The Reparenting Model was developed for cases when the Release 1 and Release 2 sources bases differ significantly and also for moving discrete features between releases.

#### Cascade Model

The company noticed that in most circumstances Release 2 is a superset of Release 1 -- Release 2 contains all of the features of Release 1, plus bugfixes and new features. When this relationship exists, a cascading hierarchy of development hierarchies was found to be very effective. In the Cascade Model the new Release workspace is a child of the previous release's Release workspace.

Linking development hierarchies in this manner was found to have a couple of advantages:

- As the Release 1 source base changes, the changes can easily be brought over for integration in Release 2.

- When development hierarchies are related in this manner they are displayed together in the `twconfig` workspace graph pane and their relationships can be easily determined using the Configuring `workspace` `children` and `parent` commands.

Figure 5 shows the relationship between Release 1 and Release 2 in the Cascade Model.

    Click for closeup.

#### Figure 5 Updating Release 2 from Release 1 (Cascade Model)

Note that changes are always brought down from the older release to the newer release. In this case, as new work is integrated in Release 1 it is brought over to Release 2.

> Note - Since you have to integrate the features from Release 1 into Release 2, you probably want to consider bringing the work over into a clone (child) of the Release_2 workspace for integration rather than directly into Release_2. Refer to "Optimizing Integration" on page 40 for details.
> Using a clone workspace provides two advantages:
> The Release_2 workspace remains open for bringovers during integration.
> Unwanted changes made during the integration can be backed out by
> reverting to the contents of Release_2.

This cascade model can be extended to include a cascade of multiple consecutive release hierarchies.

    Click for closeup.

#### Figure 6 A Three-Release Cascade

#### Reparenting Model

The development groups found that in some situations it is not practical to transfer changes between hierarchies through its release workspaces. In these cases they decided that it is better to propagate discrete features directly from the development level of a release hierarchy to the development or integration level of another. Consider the following cases:

- A feature intended for Release 1 cannot be included in that release due to time-to-market considerations, but will be included in Release 2. The feature's development workspace can be reparented directly to the Release 2 hierarchy. The company calls this process "late binding of a feature to a release."

- The source base for Release 2 diverges so significantly from Release 1 that Release 2 cannot be a child of Release 1. If a Release 1 developer implements a feature that happens to be compatible with Release 2, the development workspace in which the feature is developed can be cloned and reparented directly from Release 1 to the Release 2 development hierarchy.

- A Release 2 developer finds and fixes a bug that is also applicable to Release 1. That developer's workspace can be cloned and reparented to the Release 1 integration workspace, or directly to the workspace of a developer working in the analogous area in the Release 1 hierarchy.

> Note - Whenever you transfer work between workspaces it is extremely important that you guard against inadvertently contaminating the reparented workspace with changes that you do not intend to transfer. One way to help prevent this type of contamination is to carefully select and limit the files that you transfer.

Figure 7 shows the steps involved in moving a feature between development hierarchies.

    Click for closeup.

#### Figure 7 Late Binding of a Feature to a Release

### Unanticipated Releases

In addition to regularly scheduled releases, the company finds itself generating releases that were not initially planned. These unanticipated releases generally fall into two categories:

- Minor releases
- Patch releases

The company developed the following strategies to accommodate these releases. Both are variations on the cascade and reparenting models discussed in the previous sections.

#### Minor Releases

A minor release is one that contains the entire product, much like a regularly scheduled release. The company denotes these types of releases with numbering schemes such as "1.1" or "1.0.1." They have found that it works well to insert these releases into the product release cascade.2

The following steps insert a minor release into the release cascade.

    Click for closeup.

#### Figure 8 Inserting a Minor Release Into the Release Cascade

  1. A child of the Release 1 release workspace is created using the bringover create transaction (A).

    A new development hierarchy is set up under the Release_1.1 workspace in which to develop Release 1.1.

  2. The Configuring reparenting command is used to reparent Release_2 to Release_1.1 (B).

  3. The Release 2 workspace is periodically updated with changes made for Release 1.1 (C).

    Click for closeup.

#### Figure 9 Updating Release 2 From Release 1.1

By inserting these minor releases into the cascade:

- It is easy to propagate the changes down the line to all releases being supported.

- The hierarchies are displayed together in the `twconfig` workspace graph pane and their relationships can be determined using the Configuring `workspace` `children` and `parent` commands.

#### Patch Releases

A patch release is one in which only a small portion of the product is released in order to correct a defect in the product. The company has found that this type of change usually best propagated to other releases using the reparenting model.3

For example, a serious bug is found in Release 1 of the company's industrial product and the company decides to produce a patch that can be distributed to customers who encounter the problem.

Figure 10 shows a patch release workspace inserted into a release cascade.

    Click for closeup.

#### Figure 10 Creating a Patch Release

The following steps create a Release 1 patch release workspace and incorporate the patch into the Release 2 development hierarchy:

  1. The bringover create transaction is used to create a child workspace (Patch_1) of Release_1 (Figure 10).

  2. A development hierarchy is created with Patch_1 as the top-level release workspace.

    The size and depth of this hierarchy depends on the number of developers assigned to work on the patch release. Generally, patch development hierarchies are relatively small.

    Click for closeup.

#### Figure 11 Reparenting the Patch Workspace

  3. After the patch is developed, tested, and released, a developer from the Release 2 development hierarchy uses the bringover transaction to integrate the patch into his workspace in the Release 2 hierarchy.

    This is best accomplished by reparenting "on-the-fly" as part of the bringover transaction (specify an alternate parent in the Transactions Window or use the `-p` option on the command-line).

##### Some Notes About Patch Releases

- The process described above is sometimes reversed. Bugs are discovered and fixed in the Release 2 hierarchy and ported back to Release 1 as a patch. In this case the clone is made from the Release 2 hierarchy and reparented to the Patch_1 workspace.

- Whenever you transfer work between workspaces it is extremely important that you guard against inadvertently contaminating the reparented workspace with changes that you do not intend to transfer. One way to help prevent this type of contamination is to carefully select and limit the files that you transfer.

- The contents of the patch workspaces are never put back to the Release 1 workspace. Putting the changes back to the release workspace would change the contents of the release archive.

- Over their lifetime, releases often end up with multiple patches. When this occurs you can either make each patch release a separate child workspace of the Release_1 workspace, or you can start a cascade of patch release workspaces like those described for release workspaces in "Cascade Model" on page 46. The Cascade Model is most useful if the patches you release are cumulative -- where the most recent patch contains everything released in all of the previous patches.

1 Instead of using the putback transaction to move the contents of the Main Integration workspace to the Release workspace, you could simply replace the Release workspace with the Main Integration workspace. An advantage of using the putback transaction is that you insure that nothing has been inadvertently changed in the Release workspace since the last update.

2 Release cascades are described in "Cascade Model" on page 46.

3 This model is described in "Reparenting Model" on page 47.