Usage models for distributed development
Which usage models work best under MultiSite? As with the single-site models, described in “Chapter 10, “Implementing UCM” on page 157”, the best usage model depends on a number of factors:
Group organization— Is the remote group organized by release or component?
Latency requirement— How closely do the groups have to work together?
Content— Are you working on models or other data types that should adhere to a strict serial development model?
Three models we like for distributed management are presented here:
Producer-consumer model—for independent, but related development
Local-integration model—where more control is useful at the remote site
Serial development model—if you have to enforce serial development
Producer-consumer model
The producer-consumer model (Figure 14-3) performs well if work is organized by component and there is not a lot of code sharing required on a daily basis to get the job done. Actually, this is the best model for remote development in general, if you can get away with it.
The main attraction of the producer-consumer model is its simplicity. The two groups work independently on their own projects, but still have a formal mechanism for code sharing.
Local integration stream
Using stream hierarchies (Figure 14-4) is similar to the producer-component model, but works better for cases where there need to be regular refreshes of code between the groups. It also works in organizations where work may not be strictly assigned by component.
The benefit of the sub-project integration model over the standard UCM stream model is that the remote site has the capability for local integrations.
Managing serial development across sites
If you have a setup with very clear separation of responsibility, and no overlapping work, then serial development is fine. Serial development is useful in small teams, where developers have multiple roles (both development and maintenance), or if the code is divided into such small files that it is unlikely that two developers work on the same file.
In “UCM stream design” on page 173 we recommend a single-stream project. How can that work in a MultiSite environment? The section that follows describes how to make mastership changes within a single stream.
Managing mastership of stream instances
ClearCase differentiates between object types and object instances. An instance of a stream is the physical stream associated with a specific element.
The cleartool lsvtree command shows the version tree of a specific file. The stream associated with that file is a stream instance.
REM set into view context then show version tree
cd /d M:stade1_cc_cook_intmsplay_datacccbk
cleartool lsvtree audit.fm
audit.fm@@main
audit.fm@@main
audit.fm@@maincc_cookbook_Integration #stream instance
audit.fm@@maincc_cookbook_Integration1When a user creates a new development stream while joining a UCM project, a new stream type is created. When that user checks out a file, the first stream instance is created. The default mastership rule is that a stream instance inherits the mastership of the type. So, generally, we do not have to be concerned about this distinction between types and objects.
You can manage distributed development against a single stream by giving away mastership of a file’s stream instance. Here is an example from the command line:
REM set into view context, then give away mastership cd /d M:stade1_cc_cook_intmsplay_datacccbk multitool chmaster tokyo audit.fm@@maincc_cookbook_Integration
Now Tokyo can modify the audit.fm file directly on the integration stream.
Change of mastership can also be done from the GUI, from the file’s version tree (Figure 14-5).
Using request for mastership (RFM)
If your sites are directly connected—you can ping the other site—you can also set up a feature called request for mastership (RFM) to handle serial development. When RFM is enabled, users can request mastership of objects mastered elsewhere. The RFM operation sends an rpc command to the remote site and does a chmaster on the object to the requesting site. On the next synchronization cycle, the requesting site masters the object.
Request for mastership is off by default, and is turned on site at a time. A Windows-style access control list determines who has rights to take mastership of what objects.
This feature is of great help when serial development is required. However, do not use this model to replace other streaming strategies. Overused, RFM can result in mastership constantly in transit from one site to the other.