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 design 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:
- 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.
- 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.
- Add resources to the project. If your project uses resources
that are in different project areas, you must create dependency relationships
with these resources.
- 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.
- 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
- 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.
- Create a change set to group your changes to resources.
- 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.
- Create, edit, or delete resources as required by the
project.
- Mark your change set or sets as complete.
- 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.
- 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.
- Deliver the changes in your workspace to the parent workspace. 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.
- Optional: Review and accept
or reject the changes made by other team members.
- 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.