Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Tools

Distributed Software Development Explained


Pablo is a software engineer at Codice Software. He can be reached at [email protected]


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).

[Click image to view at full size]
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.

[Click image to view at full size]
Figure 2: Multi-site development

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).

[Click image to view at full size]
Figure 3: Multi-site development at branch level.

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.

[Click image to view at full size]
Figure 4: Ownership-based multi-site

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.