Setting up SharePoint 2010 CI process with Team City

In this article and screen cast we will discuss the idea behind the CI process and focus on the technical tricks that we need to make in order to get this working for a SharePoint 2010 project using Team City and Subversion.

One of the first things that you will want to do for any development project is setup your Continuous Integrationprocess. The value of having a server automatically monitor your source code repository for changes and validating they work is immense

Its worth mentioning that doing Continuous Integration is not something you will want to leave until later in the project.  Waiting means the solution gets bigger and more complex which in turn make the setup more comples.   My recommendation:  Get this configured early, during Sprint 0  (i.e. before you write any real production code) if at all possible.

The basic CI Process

The diagram below shows the normal process that occurs.  

(1) a developer checks in some code changes to the source code repository.

(2) The CI server monitors the source code repository for any changes

When changes are detected the code is retrieved and the automated build is started.  This build will normally include running Unit, Integration and Build Verification tests.

(3) The success or failure of the automated build is reported back to the Team (including the developer).

In some teams breaking the build means the developer has a forfeit of some sort.  The idea is to encourage team work but also to discourage broken builds.

Continuous Integration 

When the build breaks!

A term I read recently, ‘Stop-the-Line’,  is used in Toyota manufacturing process where any problem results in the production line being stopped until the cause of the problem is found, resolved and ideally prevented from re-occurring.    

This should be the same when a build breaks; the whole Team should stop and help get the build working again.  It is not just a problem for the developer who last checked in – the whole team need the process and need the builds to be working.

Setting Up in Sprint 0

The actual process described above is a little into the development cycle, when the build is in place and when the team are working on production code.   Before this can happen there needs to be a process put in place.  I refer to this initial as getting the strawman solution done.

definition: Strawman

In general, a strawman is an object, document, person, or argument that temporarily stands in for and is intended to be “knocked down” by something more substantial.    


The aim is to take some code, which will be replaced hence the Strawman term through the CI process and get the team build notifications working.   You should aim to prove the successful builds but also what happens when the build fails.  Did the team get notified?  and did they react?

The Strawman Exercise

21apps is a small and geographically dispersed team,  we make extensive use of cloud based services for things like source control as they prove to be cost effective and flexible and our strawman  process tends to follow these steps:

1) Create a repository for the project  (Hosted Subversion)

2) Create the strawman project  (Simple ‘hello world’ web part)

3) Create a simple build script  – small steps mean a successful compile is our objective

4) Create a automated build configuration on our CI server – we use Team City

5) Prove the successful and failed builds

In this post we are focusing on step (4) setting up Team City as our CI server. 

To make this easier I have provided a quick video walkthrough on what we have done for the early builds of Project Aberdovey- the process will be very similar for your SharePoint 2010 solutions.


SharePoint 2010 – CI with TeamCity from Andrew Woodward on Vimeo.


Video Spotlights

Key areas that are highlighted in the video that you will enable you to build SharePoint 2010 projects in Team City.

If you are using MSBuild ensure you set the MSBuild version to Microsoft.Net Framework 3.5 and x64 run platform.



Force Team City to use MSBuild 4.0 as this is needed by adding the Environment Variable

Name: MSBuild

Reference Syntax: %env.MSBuild%

Value: %system.DotNetFramework4.0_x86_Path%


This entry was posted in Development, SharePoint and tagged , , . Bookmark the permalink.
  • Jim Prince

    Great post Andrew! Just wondering what software you used to record your screen-cast?

    Hope you're well.


  • AndrewWoody

    I used Camtasia Studio, web cam was using Lifecam software rather than the built in camera features if Camtasia.

  • Jim Prince

    I guessed it would that, Camtasia Studio is as good as it gets.

  • Pingback: SharePoint 2010: Recopilatorio de enlaces interesantes (V)! « Pasión por la tecnología…

  • Pingback: SharePoint 2010: Recopilatorio de enlaces interesantes (V)! - Blog del CIIN

  • Ketul Patel

    Hi do you mind sharing the simple MSBuild Script, I am right now using Visual Studio as a build runner in team city and want to use MSBuild but don't know much about Build scripts

  • AndrewWoody

    My colleague James Fisk is doing a talk on this subject at SharePoint User Group in Manchester.

    He should make his MSBuild scripts available from that talk.

  • Daniel

    Timely and informative post. Today, I have been asked to recommend a CI server for a SP2010 project . Tony (Wor) at ID mentioned Team City to me sometime ago seems as ever he made a smart choice. I have couple of questions:
    1) Do think there will be any issues if I install team city on the dev single server, SP2010 Farm – in terms of load. Saves on tin I am told….
    2) Are those James Fisk or perhaps your sample MSBuild Scripts available to view or download.


  • AndrewWoody

    1) Yes that is exactly what we do
    2) James should have sent you something by email

  • Ben Weeks

    Nice post Andrew. Two questions:

    (a) Do you normally have SP also installed on the Build Server or are you just confirming it builds successfully and confirms to SPDisposeChecker etc.?
    (b) Do you prefer nightly builds or continuous integration to build on check-in for example?



  • AndrewWoody

    Ben, sorry for the delay.

    a) We do install SharePoint on the build server if we need to do any integration testing. If you are just doing things like FxCop, SPDisposeCheck and Unit Testing with full isolation then you can manage without.
    b) On checkin to validate the code, unit tests etc., in addition nightly builds for more involved integration and coded UI tests.

  • Thorsten Hans

    Hi Andrew,

    nice post. I’m also doing CI for my SharePoint projects, but I don’t prefer TC as Build Server or Build Agent. I prefer just plain MSBuild. By using MSBuild I’m able to do a kind of local CI befor I push my latest changes across to the SourceControl. Sure MSBuils isn’t as comfortable as TC but I tried all of them including TC, TeamBuild 2010, Rake and MSBuild. I’n my opinion only two valid build engines pass my tests which are MSBuild and Rake on the other hand. By using such a basic technologie which is easy to extend I’m able to achieve all the requirements that are present for a front-to-end build within the SharePoint context.

    What’s your opinion right now, over a year after publishing this post?

  • AndrewWoody

    We use MSBuild scripts, so like you we can run local build from the command line.  I like TC as it gives the CI based on checkin – also you can do personal builds but this something done by the dev locally before checking during thier checkin dance.

    I’ve seen over the past year some good use of TFS and for bigger agile teams, with dedicated scrum masters and a reasonable budget that this does add some value.