CM and ALM for Global Software Development

a centralized scenario.

Finally, there are multiple on-line backups of the repository, which reduces the need for local backups and allows for rapid disaster recovery. Ideally, if there were a local CM server disk crash, users would link to a different site and continue working, perhaps with the delays observed by a remote user.

Still, there are caveats. If we depend on each site to act independently on its repository, we must ensure that the CM solution behaves identically at each site. This may mean using the exact same environment and platform at each site or it may mean using tools that will guarantee platform and environment independence; I prefer the latter so as not to restrict the IT organization at each site.

I recommend using repositories that are easily audited for synchronization. What happens if a CM software bug manifests itself on one platform but not another, or in one release but not another? It might be fair to require all sites to run the same version of the CM software, but an operating system condition (e.g. “disk full”) or a human error can cause a difference in operation. I would feel better if I could know whether or not the repositories are all in sync. If they are not, recovery must be fast and simple.

Ideally, we want the tool to look and feel like it runs on a centralized repository while at the same time reaping the benefits of synchronous multiple site operation.

Distributed ALM
Distributed development doesn’t end with the best “CM” (i.e. source code control) solution.  It’s one thing to support global development from a source code perspective, but quite another from a product perspective. The entire application life-cycle has to be managed.

Sales managers around the world need to understand the differences between the new release and what’s at their customer’s site.  Developers need to have current priority lists, especially in an agile environment. Technical writers need to peruse the product repository to ensure documentation they write accurately reflects the state of the product.

So how do some common tools deal with global development? Well to start with, centralized tools will just extend the tool set from centralized SCM to centralized ALM.

CollabNet provides layered centralized ALM component products for Subversion. As centralized solutions, typically in the cloud, there is no issue here. Similarly, Perforce runs primarily as a centralized solution and has a few companion products that have a similar centralized architecture. Serena’s Dimensions is a centralized solution for its entire ALM offering.

IBM’s ClearCase, a distributed data solution, is a source code repository, but it’s companion product, ClearQuest, supports many of the other ALM functions. Each has it’s own multiple-site solution and they work together, though with a fair bit of glue.

Neuma’s CM+ extends its synchronous multiple site operation through all ALM functions. In this case, there’s only one capability that has to be maintained and monitored, and all ALM data is always globally available. CM+ also includes the ability to selectively exclude classes of data from specific sites, as might be required for security reasons.

GIT, primarily a distributed data solution, is not easily expanded to support ALM solutions, at least not with the same architecture. Typically, ALM is handled through centralized third-party tools which complement the distributed GIT operation. This is not necessarily bad, but GIT’s architecture makes it more difficult to grow into a full ALM solution and even beyond source code control into a full CM solution.

Going Global?
There are obviously good or bad choices you can make when selecting technology based on a global development