Remote Software Development Using the Configuring Tool |
 |
This topic discusses how a group of developers at a U.S. software company successfully use Configuring to coordinate concurrent compiler development between the United States and Russia.
The compiler development group decided that Configuring provides the means by which they can keep work at both sites synchronized and manage the transfer of files and merging of changes made simultaneously at both sites.
To maintain consistency, Configuring enforces a single-writer model -- only one transaction that alters data can proceed in a workspace at a time. Concurrency is achieved by the developers working concurrently in their own workspaces and then updating a central integration workspace sequentially, one at a time. From Configuring's perspective, both Bridge workspaces in this model function together as a single virtual workspace.
If both sites execute bringover transactions to their Bridge workspaces simultaneously, it is equivalent to executing two simultaneous bringover transactions from two different workspaces into a single workspace. This breaks the Configuring single-writer paradigm; under normal (non-remote) circumstances Configuring does not permit this to happen.
Transferring File Changes Between Sites
After the group determined the fundamental model they would use, they had to decide how they intended to transfer the updates between the two sites. After analyzing the situation they realized that there is an inherent trade-off -- the less information they transferred between sites, the more additional overhead was required.
The group decided that it was crucial for them to be able to transfer data via email -- this eliminated Option 1. They felt it important to reduce as much as possible the amount of data they send between the sites, even at the added cost of additional administrative work at both sites -- for this reason they chose Option 3.
Option 1
Transferring the entire Bridge workspace makes the process virtually the same as if the Russian site's Bridge workspace was actually a child of the U.S. Integration workspace (and vice versa). With this option, except for the transit delay, Configuring is used normally.
Figure 14 Transferring the Entire Bridge Workspace (Option 1)
Note - As mentioned in the previous section it is crucial that the two Bridge workspaces stay synchronized. After it has been updated with changes from the Integration workspace, the Russian Bridge workspace must not be altered until it is in turn updated with changes from U.S. The Configuring access control facility can be used to lock the workspace against any changes.
The advantage of this method over Option 1 is that you can greatly reduce the amount of data you transfer between sites. This reduction in data size might enable you to transfer updates via email, saving time and expense over other methods such as shipping tapes.
The disadvantage of this method over Option 1 is that more human intervention is required. A few additional steps are added to the process and people are required to do more work.
