You need a team in San Diego and a team in Beijing working on the same code base. You're already looking into the different source-code management (SCM) possibilities to cover scenarios when network connections are not always reliable or fast enough to ensure that your developers aren't stopped waiting for changes to be submitted or retrieved. And what's even more important, you're looking for the right ways to work in such scenario. If that's your case, let's see how true Distributed Software Development (DSD) can help.
In a previous article I introduced the basics of DSD, highlighting the differences between central and multi-site software development. I then examined the distributed path from proxy based to true distributed systems.
So at this point, your question is: "Okay, how can I set it up so my teams can seamlessly work even when they're worlds apart?"
While there are several alternatives, in this article I focus on the multi-site family as one of the possible solutions and develop it to reach full distributed scenarios. Granted, what I call "full replication" is almost the same as distributed on the technical side, because the two modes support concurrent changes to happen in different locations. From a process point of view, however, I limit full replication to server-based distributed development while distributed only focuses on scenarios where individual developers are running their own SCM system and pushing and fetching changes back and forth with peers (see Figure 1).
The Multi-site Deployment
Our requirements are clear: We have to allow our two distant teams to work together on a single code base. VPN-based solutions are not an option due to the possible network unreliability. Hence, Figure 2 depicts a typical solution.
Between them, Site A and Site B have two servers, one at each location, which lets their respective teams make modifications on the code base. The servers have to be synchronized periodically. The frequency of synchronization varies, depending on the development methodology. Simply put: When single branch development is chosen, synchronization will be more frequent. However. if heavily branched strategies are set up, synchronization won't happen that often.
The details of setting up a multi-site SCM environment varies from product to product. Once the design is clear, it can be a matter of a few minutes or a really tough process requiring experienced personnel. Fortunately new solutions greatly simplify the set up and overall replication process compared to older ones.
Once the servers are in place, and considering the original code base is at Site A, a replica has to be created at Site B (Figure 3).
Ownership-based Multi-site
Some systems (Clearcase, for instance) only support ownership-based multi-site. What does this mean? It basically means that concurrent changes can't happen on the same branch on different locations. To prevent it, only one site at a time can be the owner of the branch, and only the owner site can let its users perform changes.
This is an important constraint, but it still allows a powerful multi-site set up to happen. Figure 4 shows how the ownership (or turn) is passed from one server to another and then changes can happen at the owner site. In Figure 4, the blue squares are changesets (or atomic commits grouping different files and folders checked in together, depending on your SCM slang). Notice that the active and disabled branches are depicted in different colors, depending on when the site has the rights to allow its users to modify them.
If only one site is able to write on the same branch at a time, how can teams work in parallel?
The answer is straightforward, although not always valid -- ownership can be based on the time zone. Suppose you've a team in Sidney and another in London. When the London team goes to sleep, their colleagues at Sidney will be starting their working day. So with this scenario, it is simple to switch masterships so that the awake office can perform changes.
Unfortunately for most of the distributed teams (and fortunately in terms of communication) their working hours overlap so the solution isn't valid when changes have to be performed simultaneously on the same branch at two sites.