TFS Migration: Sharing common code

In this latest installment of recording our team’s migration to Team Foundation Server 2010, I’ll be describing how we organized and share our common code libraries.

The scenario is quite common. We have a Application that provides specific line of business functionality. It leverages several Common libraries that provide underlying functionality that are used by all of the Applications built and supported by our team.

Previously, when using Visual SourceSafe, we would share these libraries by using the ‘Add Project from Source Control’ feature in Visual Studio to add the common projects to our Application’s solution.

TFS guidance offered several approaches to sharing these libraries across Applications. The primary approaches are:

1. Workspace Mapping – add a directory mapping to your workspace for the shared library so it will be updated to your local box alongside your application’s directory structure. This is essentially a client-side solution, since Workspaces are managed on the local development system.
2. Branching and Merging – use the improved Branching capability in TFS to branch the common project into the source control structure of the application project. This is essentially a server-side solution, since the branched code is maintained by Source Control and will be updated by anyone who does a ‘Get Latest’ on the project directory.

We have adopted the Branching and Merging approach, but it was not without a lot of experimentation of both methods. In the end, here were the key factors in our choice.

1. Server side vs. client side. A big part of our goal in organizing our projects is the ability to set up a new development environment quickly. The server side Branch and Merge strategy supports this goal by eliminating one more step (that is, configuring the Workspace) in preparing a new dev environment.
2. Isolation of potential changes. While it is more and more infrequent, changes do occur to the common libraries. By leveraging a Branch, the branched copy of the common project is isolated from all other consumers of that library, until the changes are merged in to the Main branch for the common library. If we were using the Workspace mapping approach, a check-in of changes would go straight to the Main branch of the shared project, which could cause a ripple effect through other Applications that are using the common code.

Still, there are other implications and adjustments for our development team, primarily propogating changes. In the case when a change to a common library is merged back to the Main branch, and it is appropriate to propogate those changes to all other consumers, a new effort is required to forward merge the common code out to its consumers. This effort is compounded if the consumer Application itself has multiple branches that would all need the updates. However for our team, this is an acceptable trade off since a) changes are infrequent, and b) the number of consuming applications is manageable. Furthermore, as we continue to expand our automated Build setup, propogation may be something that can be scripted in as part of a nightly build of the common projects.

For more information about these approaches, you can check out the Patterns & Practices guidance for Team Development with TFS.