Management of shared resources

When you work in a collaborative team environment, several teams and team members might work on different versions of a product (or project). To ensure that your teams access the correct resource (artifact) versions, you can use built-in configuration management capabilities to organize a lifecycle management product's resources into unique sets (configurations). There are two types of configurations: snapshots and workspaces.
Snapshots represent the state of a set of resources at a specific point in time; these resources can no longer be modified. Create a snapshot to freeze the state of the resources in a workspace at a specific point in time and prevent further changes to that set of resources.

Workspaces contain sets of resources that you and team members can modify.

Other lifecycle products might use different terms for the concepts that are discussed in this topic:

In your lifecycle product, you can specify which configuration to use by selecting it from the Configuration Management menu.

In the following simple scenario, a team begins product development by using a workspace named Great New Product. Over time, additional configurations are created, and resources are delivered to, or changed in, the workspaces. After the “:” (colon) in a resource name, you see an arbitrary version number assigned by the lifecycle product. “Resource A:101” means “Resource A, version 101”.
Figure 1. Configurations change during a project as team members create configurations and deliver changes
Timeline showing how configurations change as team members create configurations, and deliver, remove, or edit versions of resources.

At the start of the project, a team member delivers Resource A and Resource B to the Great New Product workspace. The lifecycle product assigns a version identifier to the resources. These resources are now available to the team members who use this workspace.

Later that afternoon, team member Bob creates a snapshot of the top-level workspace because his team wants to capture the current state of the resources in the project and prevent further changes to these versions. Later, the team might use this snapshot to see how resources have changed, or another project team might use it as a starting point for a new project milestone.

The next day, team member Charlie creates a workspace named Great New Product Workspace 1, which is based on the Great New Product March 2014 snapshot. Charlie and his team members use this new workspace to start development on a new project milestone. The versions of the resources in the snapshot become the initial versions in the new workspace. Team members can edit the versions of the resources that are listed in the workspace (therefore creating new versions), deliver other resources, and remove resources from the workspace.

A week later, team member Dan delivers a change set that updates Resource B; this delivery changes the version that is associated with the Great New Product Workspace 1 workspace. Dan’s team members now see the updated version of the resource.

The next day, team member Joe delivers Resource D to the Great New Product Workspace 1 workspace. The lifecycle product assigns a version identifier “103” to this version, which the workspace now references.

Frank delivers his changes to Resource C to the top-level workspace. The lifecycle product assigns a version identifier “202” to this version, which this workspace now references.

A team leader or administrator typically assigns two types of permissions so that team members can access resources and use configurations:

Visibility of changes to resources

Use change sets to group your changes to resources. A change set is associated with the workspace in which it is created. To make the changes in the change set visible in the corresponding workspace, you must share them.

This content applies to version 4.0.3 or later. To then make those changes visible to a different workspace, you must deliver the changes from the workspace to either an assigned flow target, or to another workspace that has a common ancestor as the workspace from which you are delivering changes.

For more information about flow targets, and delivering and merging changes, see the links to the related topics.

Permissions for configurations and change sets

The roles and operations that are assigned in the Configuration Management application complement, but do not replace, the permissions that are assigned in the lifecycle management product. Permissions for lifecycle management products vary; see the administration pages or the online help for that product.

Typically an administrator or team lead assigns configuration management permissions, which include the following operations:
  • Creating or modifying (renaming) configurations
  • Modifying the change sets of other team members
  • Archiving or restoring configurations
  • Merging changes
  • Assigning write permissions to specific team areas

For the complete list of permissions, in the Configuration Management application, see the Permissions page of the appropriate Configuration Management project area.

Dependencies on resources in other spaces

If your workspace requires a version of a resource that exists in a snapshot in another configuration space, you can create a dependency on that snapshot. When you add a dependency on a snapshot, all the resources in the snapshot are included in the scope of the workspace and, therefore, to all the project areas that use the configuration space in which the workspace belongs.

You can only create dependencies on snapshots that are not in the same configuration space as the current configuration.

You can specify dependencies on snapshots only, not workspaces, because snapshots are immutable.

Administrators: organization of Configuration Management application concepts

The Configuration Management application manages the organization of versions of resources and other configuration management capabilities.

For team leaders or administrators, here is a simple example of how to apply the concepts of a lifecycle product and the Configuration Management application to manage the development of different versions of widgets. In the lifecycle product, a team leader or administrator creates a project area named “Great New Product”, and then associates this project area with a new configuration space named Great New Product. Configuration spaces organize configurations (workspaces and snapshots); configurations reference versions of artifacts in lifecycle products. When the configuration space is created, a top-level workspace named Great New Product is created automatically. Whether team members deliver resources to this top-level workspace is determined by the rules of engagement for that project.
Figure 2. The Configuration Management application uses several mechanisms to organize references to versions of resources so that projects use the correct versions for product development.
The
Configuration Management application uses several mechanisms to organize
references to versions of resources so that projects use the correct
versions for product development. Click to read more about project areas Click to read more about configuration spaces Click to read more about configurations Click to read more about configurations Click to read more about configurations

Project areas in lifecycle management products

In a lifecycle management product, teams work within a project area. A project area is an administratively defined area of the repository where information about one or more projects is stored. This information includes the project deliverables, team structure, process, and schedule. Typically, resources are organized into separate project areas so that there is one project area for each logical group of information. For more information about project areas, see the related link at the end of this topic.

The following concepts are specific to the Configuration Management application.

Configuration spaces

In the Configuration Management application, a configuration space is a mechanism for organizing workspaces and snapshots. When you create a project area in a lifecycle product, you can assign the new project area to an existing configuration space, or create a configuration space.

After you associate a lifecycle management project area with a configuration space, all the workspaces and snapshots in the configuration space are available in that project area. This feature includes these advantages:
  • Users can change resources that are located in different project areas from a single configuration context.
  • Administrators and users can take snapshots that capture the versions of all the resources across the multiple project areas that share a workspace.

After you associate a project with a configuration space, you cannot associate that project with a different configuration space.

Configurations

A configuration is a unique set of versions of resources. Configurations organize versions of resources into groups so that teams work on the correct versions of resources. There are two types of configurations: snapshots and workspaces.

There are two types of configurations:
  • Snapshot (might also be called a baseline): A configuration that identifies a set of resources and their versions in a workspace at the time the snapshot was created. The versions of resources in a snapshot cannot be modified.
    • You can comment on, but not edit, the resources in a snapshot.
    • You can create a snapshot at any time in the project lifecycle. For example, you might create a snapshot before starting a new stream or work, before or after reaching a project milestone, after importing resources into an application, or after reviewing specific artifacts.

    After you modify resources, you can go back to the snapshot to see how the resources have changed.

  • Workspace (might also be called a flow target, or stream): Each configuration space contains a default, top-level workspace (created automatically by the Configuration Management application), plus other workspaces that you and team members create. The workspaces themselves can contain multiple snapshots and workspaces. For example, in the Great New Product scenario, you might define the following workspaces for different teams:
    • Application logic
    • Database logic
    • User interface

    To add, edit, and remove versions of resources in workspaces, you must have the corresponding permissions assigned to you or your role in the Configuration Management application. To make your workspace changes visible to other team members, deliver your changes from your workspace to a flow target, which is also a workspace.

    When you create a workspace, you can select a snapshot on which to base the new workspace. You can also create a workspace based on the contents of another workspace in the same configuration space. For example, in the preceding scenario, you can create a workspace named GNP-WS2 based on Great New Product Workspace 1. The versions of the resources in the new workspace are the same as those resources in the selected workspace. A corresponding snapshot is also created. If you add, edit, or remove resources in the new workspace, you do not affect the resources in other workspace.

    If your workspace requires resources in a workspace that is in a different configuration space, you must take a snapshot of the latter workspace, and then in your workspace specify a dependency on that snapshot.


Feedback