Automated SharePoint builds/UI testing–slide deck

It took a few days as I wanted to add screenshots from the demos, but I’ve now published my deck from my talk at the SharePoint Best Practices Conference. I had a great time presenting, and although the prep for this talk was harder than others I’ve done I was happy with how it turned out. I think this subject is starting to get a lot more attention, and you know there’s interest in the topic when you end up giving a repeat demo in the speaker room to fellow speakers who couldn’t attend the talk. The talk is oriented around Team Foundation Server 2010 for the build platform. Here’s a summary of one of the demos:

• Developer checks in (a breaking change to the data access layer in my demo) and an automated build is triggered
• Assemblies and WSPs are built (in release mode) and deployed to remote SharePoint server
• Once deployment is complete, the app pool is warmed up and we start hitting the site with automated UI tests (a feature of Visual Studio 2010 Premium and above)
• If a test fails, the build is a failure and all developers are notified (via the TFS build notification tool)
• Build manager/developer checks build report and sees:
• Screenshot of failing UI test
• Critical entries from the event log at the time
• >> Build manager/developer now understands why latest code change broke the build
  
• “Added value” bonus demo
• Same process but with the following data also captured:
• Code profiling (see which bits of code should be optimized)
• IntelliTrace (start a debugging session at the exception hit during the test)
• Video recording of UI tests (not just screenshot)

The idea of course, is that if this information is being surfaced every 24 hours (or perhaps even more frequently from builds throughout the day), then it’s easy to quickly identify problems as code is written. This can lead to a greater chance of success since bugs and other issues are driven out sooner, reducing the cost to fix.

Download/view the slide deck

http://slidesha.re/gSQnyD

The future

I got a lot of positive feedback on the talk and it convinced me to do a blog series on this subject. Whilst I know some folks will instantly dismiss this as not being relevant to them, my take is that any SharePoint 2010 project which has some custom code (say above 3 Visual Studio projects) and has Team Foundation Server should at least do the “first level” of automating the build (building assemblies and WSPs) – the build itself takes minutes to configure (though a build server is a prerequisite), and can bring significant benefits.

Also, it looks like I’ll be working with Microsoft (Kirk Evans in particular) on an MSDN whitepaper on the topic. This will be a more formal treatment of many of the principles/techniques I plan to outline in my blog series, and will hopefully become a valuable resource to those looking to implement automated builds.