Continuous integration (automated builds) for SharePoint 2010

Great set of articles being build by Chris O'Brien (once again), Kirk Evans and Mike Morton (Microsoft).

First important thing to notice: when to really consider using automated builds (quoting Chris O'Brien):

• "Development-oriented – perhaps with more than, say, 3 Visual Studio projects
• Multiple developers
• Fairly long-running (e.g. > 2-3 months; to give the team a chance to implement CI alongside the actual deliverables)"

Most projects you are involved in will probably meet these requirements, which means, "YES, I need it!".

Read the articles already released: first part by Chris O'Brien on the reasons to do it and the second by Mike Morton regarding the installation of TFS.

From my point of view, it is a great investment that will pay off in the end of the project, with a more robust, streamlined and responsible development strategy. It is definitely true that doing it with a SharePoint project is a much more challenging process that with a plain .NET development, but not doing it will most certainly lead to a worse final result. Keep that in mind, and don't be lazy!

Something that has been on my mind for the last days, that I will pursue with further investigation, is developing all the SharePoint objects using PowerShell scripts. This is a usual practice for SQL developers, so why not make it usual in SharePoint dev? It ensures that all developers can have an updated version of your portal in their own machine/dev environment and that you can, at every point in time, check what went wrong or quickly reset a specific build to see if an erratic behavior was already present.