Which Build Servers in SharePoint – The Results
The numbers are in and I think this small sample really gives a good view as to the way people are approaching their SharePoint development projects.
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.
