At Parasoft, we've spent considerable time using both of the previously-discussed approaches for sharing source code across geographically-distributed teams (producing pre-packaged bundles of compiled code for each module and sharing raw source code). Ultimately, we found that sharing raw source code is the best long-term solution.
Sharing pre-compiled components is good for a first start. In fact many software component vendors do this.
However, the reasons for popularity of open source software also apply with distributed development within one company. Raw source code facilitates easier debugging and understanding of each module involved in the larger application. Separate teams can help each other out by making revisions to the other team’s source code followed by a review. The result is more agile development on a global scale.
Here are some of the key lessons that we learned for reducing the pain of shared source code adoption:
1. Use Multiple Source Control Servers
Setting a source control server in each location will minimize the impact of slow network traffic across continents. Each group keeps the source code for which they are responsible in their local source control server. With this setup, frequent modifications to the repository will be fast.
2. Stagger Source Shadowing
Another effective strategy is to shadow source from other locations at scheduled times in order to reduce the impact of slow network traffic from those repositories. The scheduled times should be set up to shadow source when it is least likely to be modified. Nightly builds should try to identify a time during the day when none of the development groups will be making modifications to the code base. If a development group in some time zone is indeed modifying code during every hour of the day, a policy should be announced to not make modifications during a certain time for the nightly build.
3. Adopt Best Practices
Code quality becomes even more important because modifications to source will be used by many groups soon after being checked in to source control. Established policies for infrastructure, coding styles, unit testing and code review are essential for maintaining the quality of shared source in the code base.
Code reviews are helpful because each group can offer a fresh perspective when reviewing changes from other groups, and interoperability problems will be identified sooner. Moreover, to further safeguard code quality, compliance with standard coding style and unit testing requirements should be verified before committing code to source control. Unit tests should exercise all functionality and be checked into source control along with the code to be shared as well.
Next week... tips on how to effectively automate and coordinate the process.
To explore additional resources on geographically-distributed development, visit our Geographically-Distributed Development Resource Center. Or, visit Parasoft's Geographically-Distributed Development page.