WorkspaceMapping.xml and Continuous Integration

Here’s one that crossed my mind when writing my previous post. I was telling about the fact we configured our continuous integration build types to do Incremental Builds in order to optimize build time. While setting this up we noticed that nobody ever bothers to change the WorkspaceMapping.xml file to point to the actual source code needed to perform a build. Basically, a standard generated WorkspaceMapping.xml file points to the root of your Team Project like this:

<?xml version=”1.0″ encoding=”utf-8″?>
<SerializedWorkspace xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <Mappings>
    <InternalMapping ServerItem=”$/MyTeamProject” LocalItem=”C:\Workspace\” Type=”Map” />
  </Mappings>
</SerializedWorkspace>

I don’t know how you guys organize your Team Project source control folder but we do it like this:

$/MyTeamProject

    +-MyTeamProject

        +-Branches

            +-Oct06

                +-Documentation

                +-Source

            +-Apr07

                +-Documentation

                +-Source

        +-Releases

        +-Trunk

            +-Documentation

            +-Source

So for us, a default setup would get all artifacts (documentation, source code, released binaries, …) from source control to the workspace located on the build server. While in fact you probably only need the ‘Source’ folder beneath the ‘Trunk’ or maybe one of the branches. This way you are eating up a lot of disk space and bandwidth.

Sample based upon our largest project in TFS:

	Download Size
Complete Project	2 Gb
Trunk Only	400 Mb
Savings	1.6 Gb

Updating the WorkspaceMapping.xml file takes care of this:

<?xml version=”1.0″ encoding=”utf-8″?>
<SerializedWorkspace xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <Mappings>
    <InternalMapping ServerItem=”$/MyTeamProject/MyTeamProject/Trunk/Source” LocalItem=”C:\Workspace\” Type=”Map” />
  </Mappings>
</SerializedWorkspace>

A nice side effect of this is that the path everything gets downloaded to gets shorter and pointing to the solution file from the build project gets easier too.