ClearCase‎ > ‎UCMpedia‎ > ‎

Docking project

More than one at Docking project can exist at the same level at the same time.

Ideally the docking projects will have sorted out all potential file merge issues before delivering to the levels above. This can be accomplished by a healthy work discipline among developers and it can be further supported simply by following the convention that  "No component is modifiable in more then one docking project at a time".

The focus in a Docking project should be on enabling common deliveries to the levels above. One person should be appointed to become the "facilitator": Making sure that all the kids in the sandbox can co-exist without scrambling each others constructions. When the kids start fighting over who has the most right to the sandbox, the facilitator will go in and be the broker. When the kids go and smash each others sand castles the facilitator will make the collaborate and work together on re-constructing the pieces that were broken.

Dependant on how much work actually need to be done in the docking project you might choose to divide the developers who joined the docking project into smaller teams. This is accomplished by setting up shared streams or team streams.

The policies for delivering to the Docking project's integration stream can be quite relaxed. Developers are of course encouraged to do thorough unit-testing on the development streams and team streams or in their own views if the use shared streams. There should be no need to enforce a serialized delivery approach to the integration stream.

Allowing developers to do concurrent deliveries to the integration stream may of course not always work out well: If developers are working on the exact same files and they haven't coordinated this on a team stream or a shared stream then there might be reserved checkouts on the integration stream preventing one delivery to take place before another is completed. This is good! It just shows that these two developers should work together instead of separated.

When a docking project attendees makes a delivery it's validated using the method agreed upon in the team. It the delivery can not be validated by the unit-test the delivery is simply cancelled - more work needs to be done on the lower leves. But if it can be  validated, then the delivery is completed and a new baseline is created immediately. The creation of the baseline will signal to the Continuous Integration server to try to validated it (the validation method used by the CI server may be more thorough than the one used for unit-testing).

If the CI server can validate the baseline it's automatically promoted and recommended. All baselines that are promoted by the CI server are candidates for Component Integration test and can be delivered to the level above the docking projects. This can be done manually by a Build manager og Configuration manager, or it can be done automatically by the CI server. Either way, the point is, that developers don't do manual deliveries to levels higher then the docking project's integration streams.

Do The Right Thing

Sort out all file merge issues before creating baselines on the dockingvproject's integration stream.

Avoid that any single UCM component is modifyable in  more then one docking project at a time.

Put your trust in the developers ability to collaborate - implement relaxed policies on docking projects.

Assign one person who takes responsibility for the current status of the Integration stream - Facilitate that someone always have focus on fixing broken baselines.