Common Projects

Another alternative is to use common projects. You can create a master project that contains three projects (team1.pj, team2.pj, and header.pj) as subprojects.

In this structure, ownership of the shared resources is flexible. Both teams may be given ownership and right to modifications on the common project.

Alternatively, you could use ACL permissions to grant ownership and modification rights to one team but not to the other. This solution suggests a second alternative where a separate team is created with responsibility for all changes in the common project. This alternative also addresses the compatibility issue in that the team making changes in the common project should be aware of the other projects that include the common project as a subproject. This ensures compatibility.

Teams 1 and 2 can now focus on updating their own code, with general confidence that shared files are compatible with their code. Any problems in compatibility can be brought to the attention of the compatibility team who can deal with the problems.

When carrying out development in this structure, users create a Sandbox of the master project and recurse into the relevant subprojects. There may be some resistance to the idea of working with files located in different subprojects. This change in working environment requires time to adjust to a new operating procedure.

Recursing from the master project raises the concern of updates and release criteria. However, this solution also offers some control over that concern. There is no requirement for users within a team to start from the master project. Instead, a user can create a Sandbox of their team’s project and then create a separate Sandbox of the common project. This separation allows for flexibility in deciding on the version of the common project that is desired.

In this situation, the common project has its own release cycles and is checkpointed on each cycle. Each team can then choose to create a build Sandbox of the common project based on a given release of the common resources and use that in their development.

Alternatively, a team may want to continue development within the common project from a given release baseline, while isolating their changes from other teams and other team’s changes from the common project. The team can then create and use a variant Sandbox of the common project.

A final alternative is to create a normal Sandbox from the common project and use it as is, accepting that it may be in a state of flux. This alternative may be acceptable, and even desirable, in the early stages of development. This type of project structure provides this flexibility and even allows for decisions to be changed during development.

Although common projects provide a flexible method for managing development processes, two issues may arise when using this approach:

The version of the common project used by an individual team is not automatically referenced with that team’s project, especially when you are using a build or variant Sandbox of the common project to ensure stability and isolate changes from other teams. Each team must keep track of the version of the common project specific to their project.

Another solution is to record the version of the common project in the build files maintained by the team. These build files can then be added to and archived with the team’s project thereby serving as a permanent record of the complete build environment including the version of the common project.

This solution requires changes to build specifications because working file locations are changed.

Windchill RV&S can manage source files anywhere on your server’s repository. Windchill RV&S identifies project members in the same directory or its subdirectories using a path relative to the project file.