There are two types of parallel development: concurrent
parallel development and parallel development for different platforms
or releases.
The following types of parallel development are common when using
shared projects.
Concurrent parallel development
Developers
can check out a working version of a shared project to perform parallel
development or to work in an insulated version of the project. A working
version of the project provides the insulation that a developer needs.
The shared version allows other developers to continue their work
on the project.
For example, if you are working in a shared
project and making changes that take several days to complete, you
want to prevent changes made by other developers from interfering
with your work. Instead of working in the shared project, check out
a working version of the shared project. The project check-out operation
creates a working project with the same members as the original project.
The newly checked-out working project contains visible and shared
objects. To maintain your insulated area, you must remove the modifiable
objects from your working project.
To check out a working version
of a shared project, follow these steps:
- Check out the project.
- Create a folder to collect your assigned tasks.
- Add the appropriate folders to your project.
- Update your project.
These four steps ensure that your working project is insulated
from changes. When you perform an update, the visible and shared objects
are no longer in your project.
After you complete all the changes
in a working project, the build manager updates the shared project
to bring in the changes.
Parallel development for different
platforms or releases
You might have several parallel versions
of a shared project in different states, and these versions might
support multiple platforms or releases.
For example, the shared
project airplane-hp_2.0s (release 2.0 of airplane
on the HP platform) might have parallel projects airplane-hp_3.0s (a
future release), airplane-hp_1.0p1 (a patch to a
previous release), and airplane-aix_2.0s (a different
platform for the current release). Version hp_2.0s is
shared, but the other parallel projects do not need to be shared.
In this example, airplane-hp_1.0p1 must be in the prep state
with a list of patches to be delivered.
Hierarchies of shared
projects are maintained using the platform and release attributes.
Continuing from the previous example, assume that the airplane project
consists of the subprojects wing, fuselage,
and rudder. When airplane-hp_2.0s is
updated, wing-hp_2.0s must be selected, not wing-hp_3.0s.
The release attribute identifies matching versions
of each subproject.
However, if you have multiple shared project
hierarchies for the same platform and release, the update operation
can select the wrong subproject version. Avoid this behavior by using
a unique project purpose to check out hierarchies that have the same
platform and release values.
For example, the following project
purpose list supports three separate hierarchies of shared projects
for the airplane project: a general purpose shared
project, a shared project for a team of structural engineers, and
a shared project for electrical engineers.
Shared: shared:
Shared
- structural: shared: structural
Shared - electrical:
shared: electrical
Instead of creating versions of
the airplane project for each of three teams, the
three teams work in three separate shared projects. All three project
hierarchies can be updated regularly to keep them synchronized. Or
each team can determine how often to bring in changes from the other
teams.