20.1 Multisite Development (Geographic Distribution)

Multisite or geographically distributed development means that different parts of a development group are in different locations, which implies that everybody does not have direct access to all configuration items. Typically, source code is shared among several development sites, but it may be all types of configuration items. The principles are the same: information must be doubled and synchronized.

Example

A company has been developing software in Denmark for many years . As part of the company's expansion plans, it buys two minor competitive companies, one in the United States and one in Europe. Staff policy dictates that each development project have participants from all three offices. It's not economically and technically possible to establish connections so staff members outside Denmark can work directly on the server in Denmark. Figure 20-1 illustrates the situation.

Figure 20-1. Multisite DevelopmentSharing Items

All development sites need all configuration items, but each office is responsible for the circled items. The offices do not have direct access to each other's machinery; all configuration items must therefore be accessible in all three places simultaneously .

Organizational Considerations

Multisite development is an organizational decision. When a company decides on multisite development, a number of derived decisions must be taken, especially

• How the connection between the development sites should be organized

  - Over the Internet, and with which bandwidth

  - Offline, via the postal service

• How the responsibility should be distributed

  - For configuration items

  - For synchronization

  - For processes that must be followed

  - For machines and their connections

• How much language and culture matter

  - In which language(s) should procedure descriptions be written

  - How should procedure descriptions be formed to make them as useful as possible

  - Which language(s) should a possible tool support

Configuration Management Considerations

The key words in connection with configuration management and multisite development are ownership and synchronization. The need for formality and automation increases with the time (different time zones or shift work) and distance that divide the people involved and with the degree of competition among them.

All development sites must follow the same processesthe same (described) procedures. This is the first thing that must be in place. If one does not agree on how things must be done, multisite development will never work. If it's not possible to synchronize processes thoroughly, the differences must be made clear, as well as how these differences should be handled. Who is responsible for maintaining the processes must also be clear.

Identification

Identification of configuration items should follow the same conventions on all development sites. In any case, the merging of the unique identification for different items should definitely be avoided. An item's identification should indicate which site is responsible for it. Each item must be owned by one site only.

Storage

What is really complicated in connection with multisite development is storage, as it's necessary to double the controlled library on each site and take care that all copies of the library are synchronized. At the same time, a site must not by accident be able to changes items the site is not responsible for. Access to all such configuration items must be for release to usage exclusively, never for production or placement in storage (access must be read-only).

The method of synchronization between the sites should be carefully considered . This may entail the transfer of changed configuration items via tape or disk sent by ordinary post to the most sophisticated automated synchronizing mechanisms. Several configuration management tools support multisite development, offering various solutions to the synchronization problem. The appropriate solution depends on the company's needs and financial capacity.

In the above example, the Danish office makes changes in the configuration items it's responsible for. These changes must be distributed to the other offices. The changes made by the other offices to items they are responsible for must be distributed as well. This is shown in Figure 20-2, where the arrows illustrate synchronization. It must be clear to everyone when synchronization takes place.

Figure 20-2. Synchronization of Multisites

Change Control

Change control must be performed centrally . The sites should not have local configuration control boards unless these boards are explicitly arranged and well motivated. On the other hand, configuration control boards with members from several or all sites will often be needed. These groups may use e-mail or Web-enabled systems.

In the ideal situation, all sites will use a common event registration system. The relevant configuration control board must treat all event registrations and channel change requests to the relevant sites. All those affected by an event registration should be informed of the progress, as well as those at a site other than the one where a change is performed.

Status Reporting

All information should be synchronized in the same way as the configuration items themselves . This will often make it possible to extract relevant status reports where needed.

Example

The following example has kindly been provided by Mr. Bjarne Mnsson of Baan CRM in Denmark. The company has two development sites: Golden (Colorado, USA) and Herlev (Denmark), each developing individual components of the product. Visual SourceSafe (VSS) is used for version control of the files. Local components are built locally on a daily basis and distributed to the other site after a successful regression test. Synchronizing the components between sites means, with the eight- hour time difference, that local components in Herlev must be ready for build by noon (4:00 A.M . Golden time) and in Golden by 10 P.M . (6:00 A.M . Herlev time). Figure 20-3 shows the synchronization process.

Figure 20-3. Synchronization

A full build has components from both sites, since local components depend on components from the other site. A build consists of both binaries (compiled components .dll, .exe), Web files (.html, .js, .asp, .xml), and a database (.mdb). This is illustrated in Figure 20-4. The full synchronization and build process consists of the following steps:

• Getting the latest binaries and Web files from the other development site

• Building (compiling) the latest source code from the local development site

• Making an installation file on all binaries and Web files

Figure 20-4. Multisite Build

Note that binaries are also stored in VSSthis facilitates a rebuild of a particular version. The code is identified in VSS by the build number after a build, using VSS's labeling function.

The release (final build) requires an extra round of distribution, because every local build depends on changed code from the other site. So the final build consists of these steps:

• At Golden (build number n 1): build with changed Golden and changed Herlev code (of build number n 2)

• At Herlev (build number n 1): build with changed Golden (of build number n 1) and changed Herlev code

• At Golden (build number n ): build with same Golden and changed Herlev code (of build number n 1)

• At Herlev (build number n ): build with same Golden (build number n ) and same Herlev code

• At Golden: test installation of build number n

• Release build number n