TechEd: Real world SharePoint Customisation - IT Pro v Developer

developer it pro microsoft sharepoint sp2010 sql server teched technology

In this session Jeremy Thake and Mark Rhodes took us through both sides of SharePoint customisation, pitting developers against IT pros.



Jermey started by taking us through a common scenario – the blame game. Customised SharePoint performs slowly, devs are guilty until they prove themselves innocent and need to prove their customisations have not caused the performance problems. Yet real world example where a simple SQL setting wasn’t applied upon installation.



IT Pros hate customisations and Developers hate the deployment process. When troubleshooting performance issues people usually get blinkered into pre-judging the cause and jumping to the wrong conclusion. Naturally a dev will blame his VM if compilation is slow, but we heard a good real life example where a dev had screwed up his build process.



If you just do a default install of SQL Server and SharePoint, accepting all the defaults then you risk slightly problematic things like not being able to backup your databases because the file path to the SQL files is too long. These kind of problems can be avoided if the two camps of IT Pro vs Developer talk to each other.



Jeremy took us through his approach to managing the various solutions for NothingButSharePoint.com – an Excel spreadsheet that recorded the information about all solutions, including location in source control and a complexity rating. Available for download here.



And a recurring theme for success – engage the IT Pro team earliy in the project. This will help them see what is coming up, plan for the deployment and eliminate surprises.



Maturity steps:

  • No Source Control
  • Source Control
  • Automated Builds
  • Automated Deployment
  • Automated Testing



The audience response to the survey “Are you running a Test environment” was surprisingly positive and showed that people are getting it. Personally I’m surprised that anyone wouldn’t have Test environment in this day and age.



A good reminder that you need to know your environment – baseline the performance of your SharePoint farm so that you test the impact of any changes or solutions. Of course this applies to all the supporting services you’ll rely upon like SQL, AD, Anti-Virus etc.



SharePoint Utility Belt

The following tools can be used to aid development and troubleshoot issues in SharePoint performance.

  • SPDisposeCheck
  • Developer Dashboard – switched on with a PowerShell command and shows the breakdown of page performance. Doesn’t cover client side issues though.
  • CKS:Dev – Community Kit for SharePoint. Visual Studio development tools for SharePoint.
  • IE 10 Developer Toolbar
  • ULS Viewer– the official one from Microsoft
  • Health Analyzer rule – custom rule from Wictor Wilen that detects if any solutions are deploy with a Debug build
  • System Center Operations Manager – powerful is setup correctly.
  • Fiddler – an oldie but a goodie



Call to Action

  • Collaborate
  • Define Roles & Responsibilities
  • Measure your ALM / CM maturity
  • Set some short term and long term goals.



The above are good common sense points for all IT projects really, but good to get them reinforced.