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.

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.    

source: Whatis.com

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%

Numbers taken from a one week poll asking people which build servers they used on their SharePoint projects.

It’s very clear from this that people are in one of 3 camps of almost identical size

• Those using Team Foundation Server
• Those that user another non Microsoft tool
• Those that don’t do anything

Team Foundation Server

Installing and using, or developing against Microsoft SharePoint Server requires a fairly big commitment to the Microsoft technology stack, so the domination of Team Foundation Server is probably to be expected.

• If your a big corporate user of SharePoint you most likely have a deal that includes TFS licenses
• You have likely committed to Microsoft as the platform of choice across the board
• If your a Microsoft Partner delivering products and solutions you will have a big investment in Microsoft licenses, and also a duty to adopt the MS recommended path
• TFS is a good solution,  and it’s getting better in 2010

Non Microsoft Tools

I was surprised by the mix of Non Microsoft tools,  having looked at what you get for free and the costs for licensing beyond that I would have expected Team City to have a bigger following.  Perhaps the reason for not being higher is jetBrains being thought of a Java based?

I bundled CruiseControl and Cruise together,  in hindsight I should have split them as they are totally different products.   I will make the assumption that most are using CruiseControl as this was really one of the first decent automated build tools to target the .Net platform.  People have got to know it an have scripted automation for their non SharePoint projects already.

Final Builder I have always liked the look of;  I really do find the whole raw XML editing that we have to do in any build automation a bit like developing against SharePoint,  it’s ok but the tools really should be better than this.   Final Builder has a great product, but the cost per user is perhaps the barrier here.

Other

Some people had build servers but didn’t use it for SharePoint – would really count those as None.

Others listed the source repository (SVN) or scripting language (msbuild, nant) so I assume that the build is done manually using batch files rather than via a dedicated build server.

Also someone listed Hudson,  something I had personally never heard of, but will bundle with the Non Microsoft Tools.

None, we don’t have a build server

This was probably the biggest surprise to me,  and perhaps not the way you might think.  I was actually surprised that only 35% of people indicated that they did not have any form of build server for their SharePoint projects.  

Based on my years of doing consultancy gigs I found that the majority of companies that I went into to do work didn’t have anything even close to an automated build server.  Heck some don’t even have source control for the code!

So I can take a couple of things from this

• People who don’t were too embarrassed to answer
• SharePoint development has moved on significantly and most teams now have proper build servers
• The readers of my blog are not representative of the wider SharePoint user base

Conclusion

There are still a lot of SharePoint teams out there that have yet to get the benefit from automating their builds,  who will undoubtedly be spending many hours manually putting things together the night before Go-Live.  

For these people, and those moving into SharePoint for the first time, there is a need to provide more information on why investing time in getting your automated build in from the start can make huge savings over the life of a project.  Providing walkthroughs on how to do this and some of the challenges you will encounter along the way.

Based on the feedback I could look at doing TFS first,  but I know that for teams with nothing setup yet this is going to be a big stumbling block.  Trying to convince you boss to roll out Team Foundation Server just so you can automate your SharePoint build is not an easy argument to have.   I will instead look at the options allowing you to get up and running quickly and more importantly without needing to get budget for licenses. 

I will start with Cruise,  and I will be dog fooding this for real on Project Aberdovey.  

Thanks to everyone who took the time to vote,  I would love to hear your own take on what the numbers mean to you and your experience with automating builds in SharePoint.