Managing change in a serial development environment

In a serial development environment, a team uses one workspace. You can create change sets to group your changes, then share your changes; the process of sharing makes your changes visible in the workspace. If you do not create a change set, each time that you save your changes to a resource, your changes are visible to the team members with whom you share the 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 design resources.

For information about setting the sharing preferences in the client extension, see the links to the related task topics.

Procedure

The workflow for managing change in a serial 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 space.

  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 serial 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. Optional: 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. Optional: 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.

  6. Optional: Use change sets to manage your changes:

    By default, in the web client, if you do not create a change set, your changes are visible in the workspace as soon as you save your changes. Each time that you save your changes, an unnamed change set is created. You can view these changes sets on the Change sets page of the workspace editor.

    By using change sets, you can create logical groupings of changed resources. Change sets 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.

  7. Create, edit, or delete resources as required by the project.
  8. Mark your change set or sets as complete. If you did not create a change set, by default, a change set is created each time that you save changes to a resource.
  9. Optional: Create a review for team members to review your changes.

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

  10. Optional: If you created change sets to group your changes, deliver the changes to the project workspace. This process is called sharing.

    After you share your changes, your changes are visible in the workspace.


Feedback