CM and ALM for Global Software Development

source code) that have to come together for separate devices or subsystems.  But even then, we’re splitting our expertise into three or four compartments rather than taking advantage of  architectural expertise across all sites.

Centralized Site
The next alternative is to use a centralized operation where all of the software resides in one site. Typically, integration builds, including nightly builds, are performed at this centralized site, with the results being distributed nightly to the other sites.

A necessary concession in such a solution is to mirror the central site to all of the other sites so that local developer and integration builds can be performed quickly. This allows for delta operations, code searches, and other methods to be performed without the latency of operating within a long distance network. Some advantages of using a centralized solution include:

• Access to a consistent set of CM data through a central repository/site ensures that queries across the project are simple and current.
• There is no need to administer the partitioning and re-synchronization of project data.
• There is a central point for simpler, consistent repository backups.

The cross-project queries are more current and generally much faster than in the “divide and conquer” scenario.Centralized repositories permit an easy cloud computing option, which has a number of advantages, including:

• Team morale is kept at a constant because nobody has a preferred site advantage. 
• Cloud solutions typically have mirroring capabilities options.
• Integration builds that are performed in the cloud are readily accessible at all sites.

However, even in the cloud, there will be response time delays typical of any remote operation.  Mirrored local sites are more responsive for complex queries, such as workspace synchronization. For small projects with hundreds of files, mirroring is not essential, but for larger ones, the delays add up.

As well, there will be costs associated with using cloud products that will not be insignificant; this includes a certain level of access administration. Whether or not these costs are offset by reduced operational costs depends on the nature of administration for your non-hosted solution.

However, network interruptions can still be a problem for remote users. Additionally, check-in operations involving numerous large files will necessarily incur longer (upload) delays for all but those at the central site. This in turn can lead to less frequent developer check-ins.

Synchronized Multiple Sites
A third alternative is to use synchronized multiple sites. In this scenario, each site is a complete CM repository of its own, with little or no dependence on other sites. A single master process, somewhere on the network, orders all transactions and typically assigns each a unique sequence number. The sites cooperate in distributing the files of the transactions to all sites.

Although there are still inherent upload delays between sites, users are able to communicate efficiently with their local repository while the onus is on the server to sort out transaction ordering and to deal with upload delays across the network.

While this may seem similar to the centralized operation scenario, it has unique advantages. For one thing, clients (users) are able to receive response times typical of the central site at all sites. Integration teams can work at each site independently if desirable; this is often the case if time zones are far apart.

Network outages are also far less likely to cause delays, even for transactions and rarely during query operations.

Users can move from one site to another without changing how they operate, since the entire repository is up-to-date and operates identically at each site. As such, separate training is not required based on location, as is the case in