Shows how to introduce automated builds and UI testing to SharePoint 2010 development projects. Team Foundation Server 2010 is used as the build platform. Includes coverage of VS2010 features such as code profiling, IntelliTrace etc.
2. About me Independent SharePoint consultant Blog: www.sharepointnutsandbolts.com Twitter: @ChrisO_Brien Book: Real World SharePoint 2010 (20 MVPs) LinkedIn: http://uk.linkedin.com/in/chrisobrienmvp
3. Problems in SP2010 dev projects Many dependencies Code, Features, timer jobs Deployment is complex e.g. No native support for WSP rollback Difficult to unit test Still not much traction in SharePoint world?
4. Problems in *large* SP2010 dev projects Tracking Hard to keep track of deployments/fixes Many developers = many deployments? Inefficiency Devs keeping environment up-to-date Inconsistent builds (or buildmaster bottleneck) Silly mistakes e.g. Incorrect versions Debug vs. Release mode Testing of actual WSPs Communication
5. Solution recipe Auto-compile of assemblies and build of WSPs Correct versions in source control Add a label in source control to help rollback Auto incrementing assembly version number Better tracking of deployments/fixes etc. Deployment of WSPs to remote SharePoint 2010 environment Test environment, not developer machine UI testing Build fails on UI test failure Developer notifications
6. Solution ingredients TFS Team Build workflow (.Net4.0) Specifies sequence of steps PowerShell Deploys WSPs, other deployment steps e.g. teardown/setup site PowerShell remoting(preferred over PsExec) Allows PS on SharePoint box to be called from build server Invoke-Command -ComputerName “foo” { script }
8. Build definition Styles: What’s the trigger? Manual, Scheduled (e.g. nightly), every check-in, Rolling builds, Gated Check-In etc. Customise workflow Mandatory for SharePoint builds Several workflows OOTB DefaultTemplate, LabTemplate
13. What is a coded UI test? Recorded on test agent desktop Support: browser (inc. AJAX), Silverlight, WPF, forms apps Generate code which can be modified (e.g. to pass data) Point and click to add assertions E.g. navigate to web part gallery, check web part present
17. Integrating coded UI tests into build Automatic if test assembly name matches filespec Default = “*test*” somewhere in assembly name Background: All tests can be run from command-line with MSTest.exe (Unit tests, Coded UI tests, Load tests, Etc.) Team Build ships with MSTest WF activity (wrapper) The OOTB workflows contain this activity Caveat: OOTB workflows must be edited to deploy WSPs and/or run coded UI tests
27. Best practices Start on day 0 of project Retro-fitting can be expensive Get fast feedback - have a lightweight/quick build run on check-in Compile all projects/build WSPs Suggestion - every SharePoint project should do this much Increment assembly versions (FileVersion) with label generated by build Leverage UI testing (with or without automated builds)
28. Resources Setting up TFS to build SharePoint Projects - http://bit.ly/9lEqnP Assembly versions in build workflow - http://bit.ly/eRPB0e Running tests as part of a build - http://bit.ly/i41eze PS remoting and SharePoint 2010 - http://bit.ly/9Cb4tF Also on my blog soon: My customized workflow and PS scripts Multi-part article series on automated builds/testing www.sharepointnutsandbolts.com
31. What you need - software Automated builds = TFS 2010 (Team Build) Server + 1 CAL free with every MSDN level Need CAL for every user who interacts Components: Build Controller, Build Agent Coded UI tests = Visual Studio 2010 Premium/Ultimate (OR ‘Test Elements’ add-on) Components: Test Controller, Test Agent
32. What you need - hardware Option 1 – the EASY button Disadvantages: Risk to source control Performance SP2010 + TFS2010 = big resource reqs Bottom line: Don’t do this with prod source control!
33. What you need - hardware Option 2 – a sample topology