Local versus centralized administration

DCM supports local and centralized administration of processes, process rules, folder templates and release definitions, or a mixture of both.

With local administration, an object is locally controlled and updated. If that object is included in a DCM transfer package to that database, it is skipped during the import phase of the DCM receive. The advantage of local administration is that it allows each database to separately control the properties of an object. This operation can be independent of the properties used in other databases. The disadvantage is that, if you want to keep properties consistent across databases, then they must be separately maintained and updated in each database. This increases the burden of maintenance.

With centralized administration, for each object there is a single master and controlling copy managed from a defined database. Changes to that object are only made in its controlling database. Copies of that object are replicated to other databases in the DCM cluster and updated with any changes made from the controlling copy. DCM allows the control of the object to be handed over from the current controlling database to some other specified database. After the handover of control, that object is then only administered in its new controlling database. Different objects can be controlled in different databases. However, a more normal usage pattern is to control all the objects, such as release definitions (or at least release definitions for a specified component), from a single database. The advantage of centralized administration is consistency across the DCM cluster and a decreased maintenance burden on build managers. The disadvantages are that changes can only be made in the controlling database and the properties of the object cannot be different in different databases.

DCM also supports a mixed approach. For some releases, a user might centrally control the release and its process rules, and for others locally control them. DCM also allows a release to be centrally controlled, but have some of the process rules for that release be locally controlled. This operation allows a different process to be implemented in a specific database. The user can take local control of a release-specific process rule in order to make some local changes for that database. The process rule remains associated with the release as a valid purpose for that release.

DCM allows users to switch between local control and centralized control models of usage. If an object has been defined in multiple databases, then it is locally controlled in each of those databases. If you want to centrally control the object, then perform these steps:

To break centralized control and revert to a locally controlled object, use the Select Controlling database dialog or command-line option and specify local control. The details of the object are unchanged. However, the object is given a new and unique cluster ID. The cluster ID denotes that it is a different object and is not to be updated on DCM receive.


Feedback