On a local area network server node, directories may be created that act as production libraries. Production libraries for a particular development project may exist on one or more network server nodes, depending upon the size and organization of the LAN.
These libraries serve as repositories for the current production-level versions of all development resources. The exact number and type of libraries created is highly dependent upon the structure of the development organization and the application under development, but the following skeleton structure is recommended.
Figure "Production Libraries on a LAN Server"
All application developers should be given read-only access to production libraries. This will enable those developers to access compilers, link-editors and programming language run-time libraries, and to access the current production-level versions of application source modules, Presentation Manager resources and test data, but not to update those production versions.
Application resources currently undergoing modification (that is, user level resources) are held in a work directory on the developer's own workstation, from which only that developer may access them. This restriction of access is implicit since only appropriately declared and configured server nodes may share their disks and directories on the network.
Production level application resources may be transparently accessed at compile or link-edit time by ensuring that each developer's compiler search path specifies the production libraries. The search path should first specify an application developer's local work directory, in order to pick up any user level resources currently being worked upon by that developer, and then search the appropriate production libraries in order to pick up production level copies of other resources not currently subject to modification by that developer. This technique ensures that each application build accesses the latest tested and baselined versions of all application resources, except for those resources that exist in the developer's local work directory, and that are therefore likely to be under test.
Each application resource should have an owner appointed at the start of development. This owner may be the application developer primarily responsible for the creation of a source module, or in the case of larger and more complex development projects, may be a developer responsible for the testing of a number of modules that together comprise a coherent code unit. In either case, the owner is given update access to the files in the production libraries that comprise the module or modules under his/her jurisdiction, and only to those files. The updating of each application resource may then be achieved in a controlled manner.
This assumes that the name of the file or files containing each application resource is known at the outset of development. This in turn requires a sound approach to application design and to the correct partitioning of the application at the design stage. It also requires the adoption of a set of file or data set naming conventions across the development organization.