Part 6 – Lessons learnt from Leveraging the SharePoint Platform

Part 1 – What is the SharePoint Platform
Part 2 – What capabilities to start with
Part 3 – How to start with the SharePoint Platform
Part 4 – Levels of leveraging the SharePoint Platform
Part 5 – Why use SharePoint as a Development Platform
Part 6 – Lessons learnt from Leveraging the SharePoint Platform

There are quite a lot of people in the SharePoint community flying the SharePoint Development flag high and proudly. The SharePointDevWiki.com is growing steadily each week and I’m extremely pleased that there are more and more community members submitting content on there.

There are plenty of people trying to take the SharePoint Development approach and using Solution Packages to deploy to the farm. But more and more I am seeing this scenarios below.

Scenario One

• The development team sit down with the client and get the requirements for their new “Intranet”
• Start off with a Solution Package and buildingSite Fields, Content Types, Lists, Pages, Web Parts androlling this into a UAT environment (or worse Production)
• The “Intranet” in UAT then gets a review from the client
• Changes are requested by the client, but the client also wants to have a “play” with the UAT environment
• Developers start off on the right foot and add a few extra Site Fields, amend the List Templates and have tested it in their Development environment
• The Dev team are then ready to deploy this to UAT…but the client has done more than “play” in this environment and wants this content in there when the Developers release the changes.

FIRST TIP: ensure they are aware that anything they do in UAT is not making it to production! UAT is very different from content STAGING environments.

• So the Dev team release the new .wsp solution package to the farm and then run a script to delete the current site collection and create a new one using the new templates and scripts…this obviously deletes any content that was in there.
• This gets a tick in the box and the site goes into Production
• Content is authored in the new production site and they want to add a new Site Field to a list that is commonly used across multiple department sites within the Intranet
• Changing the List Template in the Solution Package and redeploying to the farm will not amend the instances of the List already created. So the Dev manually makes these changes and so the spiral of pain starts…

Take this scenario 6 months down the line, the Dev no longer bothers updating the solution package as he is doing it all manually in production anyway and no need to go back and change it in source control…”that’s not used anymore anyway”.

Scenario Two

Scenario two steps in where Devs originally deployed style sheets to the Style Sheets library using Solution Packages and then someone gets hold of SharePoint Designer and ignores the warnings and modifies the style sheet here. Lots of changes are made…but not put back into the source style sheet in the solution package.
Later that month a web part C# file changes and a new style is added to the style sheet in the Solution package. The new package is redeployed…guess what, it’s going to redeploy the style sheet but not overwrite the one in the site because it’s broken its ties with the original source! So the web part will not find that style and not render properly.

TIP 2: lock down files deployed with solution packages so that they can only be changed via deployment. Do this via ‘sealing’ elements and also via permissions on items.

TIP 3: don’t let developers near the production and UAT boxes. Don’t let their dirty fingers anywhere near the 12 hive directly! Get administrators to deploy to UAT and Production using WSPs and change scripts.

Why does all this happen?

The biggest problem is that developers want to be able to automate the entire setup process especially in a build server scenario and this is why everything initially ends up being deployed via a Solution Package.

TIP 4: draw a line between what is development and what is customisation.

Either do everything in Development or do everything in customisation for an element e.g. don’t build your event receivers in a dll and package with a WSP, and have a List Template in the wsp, but then manually use a tool like Event Receiver Manager to add the event receiver! On creating the list via a Site Definition or via a Feature, use a Feature Receiver to attach the event receiver there and then! It’s self documenting that way!

Whatever you do, document where each type of element sits and where it will be found: in a WSP, update script, command line up, manual steps etc.

Below is an example table that shows the boundaries between elements. Note this is by no means complete, but just to give you an idea…plenty of things in Development may sit in Customisation for a lot of teams. You can also give this to external integrators your team may use for implementations to make sure EVERYONE works the same way.

TIP 6: Remember that changing elements won’t affect their instances e.g. List Templates, Site Templates, Workflow Instances. All the other elements are referenced and linked and will be automatically updated once pushed out into the Farm.

To modify existing instances you will need to provide update scripts using the object model either as custom window console application or powershell script.

TIP 7: Get your dev team to first off create a script that deletes the site collection and recreates the site collection (using custom Site Defintion if approach taken) and then run the scripts to populate content required. Use this script when in own Dev Virtual Machine AND Shared Development Environment AND Build Server.

TIP 8: Always keep UAT and Production one change step away from each other. Always deploy to UAT and Prod using WSPs, but also use update scripts rather than deleting Site collection and creating it again! Have the ability to take the approach of Updating in Shared Dev environment (by taking snapshot of UAT/Prod) to test update scripts before going to UAT.

Conclusion

Well this is the end of this 6 part series on Leveraging the Platform. Hopefully it’s been useful to you. Very shortly I will be placing some more ideas up on the SharePointDevWiki.com around these change control processes to help SharePoint Server teams with these tasks!