Parallel development and shared projects

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:

  1. Check out the project.
  2. Create a folder to collect your assigned tasks.
  3. Add the appropriate folders to your project.
  4. 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.


Feedback