Managing change in a parallel development environment

In a parallel development environment, each team member can have their own workspace, or one team can share a workspace. To make changes visible to other team members or teams, you must deliver the changes to the parent workspace.

Before you begin

You should be familiar with project areas, configuration spaces, snapshots, workspaces, and change sets, which are described in Management of shared resources.

You should also understand the difference between sharing changes with a workspace and delivering changes to a parent workspace. For more information, see the link to the related concept at the end of this topic.

Procedure

The workflow for managing change in a collaborative development environment includes the following high-level steps:

  1. Create and configure a project area; then add members to the project area. If your collaborative development environment has multiple teams, you might create a project area for each team. By default, a working environment, also called workspace configuration or workspace, is created for each project area.
  2. Associate the project area with a configuration space, which is also called a space. Complete this step for each project area that you create in step 1. You cannot change this association after it is made. If the configuration space does not exist for your project area, you must create it.

    In a collaborative development environment, you typically associate multiple project areas with the same space. As a result of sharing the same space, multiple project areas implicitly share working environments, also called configurations. As a result of this sharing, teams do not have to manually synchronize their working environments.

    Although project areas implicitly share configurations, only the resources for a specific project area are shown when team members view configurations.

  3. Add resources to the project. If your project uses resources that are in different project areas, you must create dependency relationships with these resources.
  4. Create a snapshot of the project.

    A snapshot is a read-only view of the project at a specific point in time. By creating a snapshot, you create a starting point for a new workspace.

    Except for the default workspace that is created when you create a project area, all workspaces must be based on a snapshot. You must create a snapshot when you want to create a workspace.

  5. Create a workspace .

    You might create a new workspace after you create a snapshot that corresponds to a milestone. A workspace represents a branch of a design or a development project, contains all the resources that are in the parent snapshot, and separates new work from other working environments.

    Depending on the structure of your collaborative development project or team environment, you might create multiple workspaces, as in the following examples:
    • One workspace for each developer, depending on whether the developers work on the same resources
    • One workspace for each team of developers, where each team works on a different component in a project
  6. Use change sets to manage your changes:

    By using change sets, you can create logical groupings of changed resources, which make it easier for other team members to review and approve your changes.

    1. Create a change set to group your changes to resources.
    2. Switch the context to the change set that you created.

      From this point on, the resources that you change are added to this change set.

    3. Create, edit, or delete resources as required by the project.
    4. Mark your change set or sets as complete.
  7. Optional: Create a review for team members to review your changes.

    The team members that you specify as reviewers receives a notification on their project dashboard.

  8. Deliver the changes in the change set to your workspace. This process is called sharing.

    After you share your changes, you can see your changes in your workspace.

  9. Deliver the changes in your workspace to flow target. Other team members are not automatically notified that you have changed shared resources; the other team members must complete the action of accepting incoming changes. As part of this process, they are given the option of accepting or rejecting incoming changes into their workspace.
  10. Optional: Review and accept or reject the changes made by other team members.
  11. At the end of the project milestone, or when you must create a new branch of a design, return to step 4 to create a working environment for the new branch or version of the design.

Feedback