I’m not trying to cover all relevant aspects of SharePoint announcements that are made the last days on Microsoft Ignite – I’m sure you’re all following it closely. I just want to highlight the most important aspects for SharePoint developers and the impact they have on my work.

Provisioning Engine

The Office365 Developer Patterns and Practices group announced a provisioning engine for provisioning SharePoint artifacts (sites, lists, fields, content types etc.). It takes a xml file with a custom syntax as the input and provisions the content using the API. It also works both ways – you can use the engine to export all content of an existing site as xml.

This is really a great news and exactly what I wanted to achieve with xSharePointProvisioning DSC module. I don’t know why they chose xml and did not directly go to DSC (or at least json) – but I will but my effort in the future in combining these things instead of creating DSC resources directly.

I don’t know how mature the engine is know – but I will have a look at it the next weeks.

I think this is really the best announcement for me and all my colleagues will love this – especially the consultants.  It also will help me to enforce the new development guidelines I propagate for some time…

Development Guidelines for SharePoint

The session “Transforming your SharePoint Full Trust Code to the Office App Model” from Bob German, Chris O’Brien, Erwin van Hunen, Frank Marasco and Vesa Juvonen was more an open discussion of the best ways to do customizations in SharePoint or O365. The debate has not yet come to an end – but the most important aspects that emerged are agreed upon by most of them:

• Do not use the feature framework to provision content. Use the API instead.
• Do only modify the master page for public facing websites or special intranet sites and we aware that is comes with the cost of not getting fixes and updates and that you have to maintain the master page yourself.
• Use themes or composite looks for branding.
• Use JavaScript hooks (UserCustomActions) for more complicated customizations

This is what I tell my customers for quit some time – and even if for the details you have from six persons six opinions – the direction in which the development evolves is obvious.

Deploying Apps with Visual Studio Release Management

In my session “DevOps für SharePoint und O365 – End 2 End” on the ALMDays 2015 in Düsseldorf I proposed to use side loading to deploy apps to SharePoint or O365 using Visual Studio Release Management. I think for customer specific apps this makes more sense then telling the customer every week that he has to update his app manually from the store. But I had some discussions afterwards with some MTC’s in Germany that said side loading should not be used in production. 

I talked about this with Steve Walker today after his session “Deep Dive into Custom App Provisioning and Deployment in Microsoft Office 365”. His opinion is, that it is ok to use side loading – you just need to disable the side loading feature after deployment.