Configuration development by a team may be carried out sequentially: developers agree on modification of configuration objects, make changes and then integrate the results. This mode is associated with a risk of accidental changes to various objects; it is therefore necessary to understand all modification processes and relationships between objects. In this case, the configuration merging should be performed by a specialist who can effectively steer the direction of development effort.
This chapter explains how to reduce errors probability, increase performance and simplify the development process through distributed configuration development.
Distributed development environment is simultaneous work of a team of users (developers) on reconfiguration (modification of the configuration), where the object modification can be made only by the developer, which has previously locked the object. In this chapter, the term “configuration” means both the main infobase configuration and any configuration extension (see p. ) connected to the infobase which is being developed.
For the distributed development environment, a repository is created, where the Designer stores the configuration. Developers can access the configuration repository either within a local network or remotely using a web server. An administrator is assigned to the repository, who creates a list of users with an access to the repository. Administrative rights can also be assigned to other users.
In the distributed development environment the configuration is considered as a set of read-only objects. In order to make changes to an object the developer has to lock it first. The object can be locked only by one user at a time. The user can lock an arbitrary number of objects not locked by other users.
Techniques for working with locked configuration objects do not differ from those used in the normal mode. The user can edit the properties of the locked object as well as add and remove subordinate objects.
To add objects, it is required that the object to which they are subordinate be locked. E. g., to add a constant, you need to lock the root configuration object. To add an attribute or object form the object itself has to be locked.
To delete an unlocked object, you should lock the object itself, as well as the object to which it is subordinate, and all its subordinate objects.
After working with locked objects, the result of their modification can be stored in the repository. On the other hand, if any of the unlocked objects have been modified, you can retrieve the updated objects immediately after adding them into the configuration repository by the author of the changes.
Results of working with the repository can be viewed in the repository history. You can open configuration versions stored in the repository to view and compare with the current configuration, database configuration, as well as various repository versions.
Configuration objects are closely interrelated. Therefore, the configuration repository maintains metadata integrity when objects are locked or stored in the repository.
In this way, the distributed development environment ensures synchronization of configuration modifications by the developer team.