Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Implementation Excellence

Approaching Code Access for Distributed Development

Written by Mario Moreira

Wednesday, 16 February 2005 16:00

There was a time when mainframe development was the norm and teams were in close physical contact only having to walk down a few feet to interact with their colleagues. However, times have changed and access to code has to be considered in a much more serious manner. Some companies have had multiple sites participate in their development efforts for upwards of two decades, but a majority of them have only been at this for the last 5 years or just undertaking this venture. The crux of distributed development is the ability to share code for development across sites via the network or via tape or disk.

Back in the early 1990s when I worked at Open Software Foundation (OSF), we had development occurring in our Cambridge, Massachusetts and Grenoble, France development shops as well as distributed development with HP, Dec, IBM, Bull, Siemens-Nixdorf, and others. We used a CM system called OSF Development Environment (lovingly pronounced “ODE”) which was a client/server TCP/IP SCM system based on RCS, which included a build component. ODE originated from the Carnegie Mellon University (CMU) b-tools via development by Glen Marcy, et al, and was extended by Damon Poole (later a co-founder of AccuRev, an innovative SCM tool released in 1999) making it truly client-server, adding merge tracking, increasing the performance, and making it more transactional in nature.

Even in those early days, ODE had a partner distribution tool called Software Update Protocol (lovingly pronounced “SUP”) developed by Steven Shafer from CMU. At OSF, we used SUP as a code synchronization tool that could replicate and distribute code to and from multiple sites. The SUP utility is still around today included with NetBSD distributions.

Why Distributed Development

Beginning in the mid-eighties, there have been continued actions by companies to acquire or merge with other companies. This led to companies having multiple sites with expert talent. When development projects are initiated, the talent needs to work together in a distributed yet effective manner. In the early days of code sharing, this would often be done via tapes and disk. Then FTP (file transfer protocol) or similar protocols came into existence, which allowed for sending or retrieving bundles of files via the network. With the advent of high bandwidth networks, this has allowed the possibility of real-time sharing of files without the need of transporting or sending the files. Personnel simply logged into a system from their remote site. However, while the network is broader than before, serious throughput and performance issues continue too exist.

Around year 2000, companies not only need all of their own company talent accessible to code, but there began a huge push in the industry to utilize low cost resources (e.g., developers and testers) from countries like India. This drive to lower cost has lead to a rapid increase in distributed development. Based on a 2003 survey of IT executives, the number of companies outsourcing applications to offshore service providers was expected to grow by 50% in 2004, with 35% of all users to outsource some piece of IT to offshore resources. This expectation has become a reality particularly with India.

Distributed development, as many of us know, is upon us. It is important for us to focus on how we can manage the distributed nature of projects. While there are many aspects to managing a distributed development project, this article will guide you through an approach for ensuring you have selected the appropriate distributed code access technology based on your distributed development needs.

Advice on Approaching Distributed Development

When considering your needs for code access in a distributed environment, it is important to perform an analysis of your situation. From this, then it is important to understand what distributed code access technology approaches there are and which may be best suited for you. From there, they you can identify a specific technology within a distributed code access technology approach.

Distributed Analysis

The first aspect to approaching distributed development is performing a Distributed Analysis. This identifies the characteristics of each application or product that is being considered for distributed development. For each application:

Identify the number of developers that will participate in development activities from each site.
Identify when in the lifecycle the additional sites will begin and end their work
Identify the complexity of the development technology used. Complexity may be derived by how much RAM the development technology requires to run and how network intensive it is. Complexity levels can include:
- Low complexity - development technology that has low RAM requirements, low network dependency or few network transactions, and ascii-text based development.
- High complexity - development technology that have high RAM requirements, high network dependency or constant network transactions, and object based development.

Distributed Direction

Once you have completed your analysis, consideration should be given to appropriate distributed code access technology approach. The application characteristics from the distributed analysis should drive the decision.

Distributed Code Access Technology Approach

Identify the technology approach in which code may be retrieved from the remote sites for development. The approach selected becomes the requirements for a technology that will support that approach. There are two primary categories of distributed technology. They include:

Distributed Site – this is when the code physically resides in two or more locations. This is applicable for all complexity (e.g., low to high) development technologies and recommended for medium to high complexity. This can be implemented in two ways (and not limited too):
- Remote Client Snapshot - this is when the application code is populated (checked out or retrieved) directly from the local server to the client at the remote site. The initial population of the code baseline to the remote client may take time and varies according to the network performance across sites. However, once a snapshot of the full baseline is on the client, single or multiple checkouts/checkins of code may be relatively quick (pending any network performance issues). This method requires low setup effort, has low network dependency (unless interacting with the server at the local site for version control or retrieval operations), and has the client working on their own without continuous reliance on the WAN or LAN. This may be recommended for projects where a small to medium number of people from remote sites are working with the local site
- Remote Server Repository – this is when the application code is populated (replicated or retrieved) from the local server to a central server at the remote site and the remote clients at the remote site retrieve code from this central remote server. The initial population (or retrieval) of the code baseline to the remote server may take time and varies according to the network performance between sites. Once the full baseline is on the remote server, periodic changes (from each site) are replicated/retrieved relatively quickly pending network performance. The clients at the remote site use the server at the remote site to version control or retrieve the code baseline with no WAN dependency. This method requires medium setup effort, has low to medium network dependency unless the code repositories are being updated by each other, and has the client working on their own without continuous reliance on the WAN. This may be recommended for projects where a medium to high number of people from remote sites are working with a local site.
Single Site with Distributed Site Access - this is when the code resides only at one site and all remote sites use the resources of the local server and/or clients where the code resides. This is applicable for low to medium complexity development technologies and recommended for low complexity development technologies depending on network performance. This can be implemented in two ways (but not limited too):
- Terminal Emulation – this is when remote personnel remotely logon to the local systems to perform development work. The remote personnel perform version control on the local server or client similar to what the local personnel do. This allows personnel to remotely log on directly to a local system where the code resides and is worked on. This method requires low setup effort and has high network (WAN) dependency. The number of personnel at remote sites that may work in this setup is directly proportional to the network bandwidth and performance to the local site, but is typically a low number of personnel. This is only recommended for low complexity development technologies.
- Terminal Services – this is when remote personnel use a local terminal services server or client to host the development technology and application code, which comes directly from the local server. The activity from the local server or client is viewed via the remote client with low network utilization. The remote personnel would perform version control on the local server or client as if it were their own client. This technology minimizes network bandwidth challenges and allows personnel to remotely utilize local systems to access and work on the code on a local system. This method requires medium setup effort and has medium network (WAN) dependency. This may be applicable for a small to medium number of personnel at remote sites working with the local site. This is only recommended for low to medium complexity development technologies

Summary

It is important to understand that there are numerous ways a distributed development team may share code. An analysis to identify the project characteristics should be input to the decision to determine which approach to take. On the other hand, selecting too simple of a distributed code access technology approach may limit or constraint development due to poor performance. On the one hand, selecting too complex a distribute code access technology approach may lead to more administrative effort that can overwhelm a small team. Ensure you select the distribute code access technology approach that is right for your development team.

For more information on how to establish a more thorough global distributed development/SCM strategy for your needs which includes working templates to help you through the distributed analysis and distribute direction process, consider reading section “5.3 Define a Global SCM/Development Strategy” in Chapter 4 (Establish an SCM Infrastructure for an Application) of the book the “Software Configuration Management Implementation Roadmap”. In the same book, consider reading section “7.5 Establish the Global SCM/Development Infrastructure” for guidance on implementing the distributed code access technology approach you selected.

References

Section “5.3 Define a Global SCM/Development Strategy” in Chapter 4 (Establish an SCM Infrastructure for an Application), p90-95 of the “Software Configuration Management Implementation Roadmap”. by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing
Section “7.5 Establish the Global SCM/Development Infrastructure” in Chapter 4 (Establish an SCM Infrastructure for an Application), p128-130 of the “Software Configuration Management Implementation Roadmap”. by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing
“Managing Distributed Software Development”, by Randy Guck, StickyMinds (www.StickyMinds.com), November 2002
“AMR Research Survey Results: 35% of Users To Outsource IT Work to Offshore Companies”, by Lance Travis, October 2003
Software Update Protocol (SUP) - ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/sup.ps

Mario Moreira is a Columnist for CM Crossroads Journal, a Director/Architect of Technology, an Author of CM publications, and has worked in the SCM field since 1986. He has experience with numerous SCM technologies and processes and has implemented SCM on over 100 applications/products, which include establishing global SCM infrastructures. He has an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience.

Mario has released a new SCM book entitled, “Software Configuration Management Implementation Roadmap.” You can find it at amazon.com www.amazon.com This book includes step-by-step guidance for implementing SCM at the organization, application, and project level and includes helpful templates on CD to get started.

You may reach Mr. Moreira by email at Mario.Moreira@cmcrossroads.com

Set as favorite

Bookmark

Email this