We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
In my last blog post about DevOps for SharePoint Online the process I presented relied a lot upon scripted deployment to SharePoint Online (O365). I wanted to expand upon that a little and explain in a little more detail about how Perficient is using PowerShell to manage our deployments for our Development, QA and Production environments.
Automating any task which is repeated can be a productivity benefit providing the time invested in developing the automation takes less time than repeating the task itself. Automation also significantly reduces chance of ‘human error’.
Automating deployments is of little benefit to light users of SharePoint who do minimal customization of SharePoint in a single O365 tenant. However, as you begin to customize more and introduce the need for testing cycles then automation starts to become valuable. When you add multiple tenants into your DevOps and add multiple developers or administrators then automated deployment can really pay huge dividends.
I think it is fair to say we are in a period of emerging standards for deployment of customizations to SharePoint Online. When we worked on-premises with SharePoint the WSP provided great deployment options especially when you consider Feature stapling. This is basically off the table with O365 and we’re looking for new best practice.
I think that the combination of PowerShell and the SharePoint Server 2013 Client Components SDK is a strong candidate for best practice automation of deployment to SharePoint Online. PowerShell gives us the lightweight scripting we need in order to move rapidly through automated builds and deployments. The Client Components SDK gives us the full Client Object Model on the administrator’s desktop allowing them to execute on a huge variety of scripted tasks. Here are a couple of useful resources on this topic, one from my colleague Roydon Gyles-Bedford whom I credit with a lot of Perficient’s thought leadership in this area:
At Perficient we have invested in PowerShell Modules which use XML configuration to drive deployment of items such as:
- Master Pages
- Page Layouts
- Content Types
- Display Templates
- Term Store Terms
The XML configuration files are pseudo-CAML (Collaborative Application Markup Language!) which is wrapped in our own markup to help the Modules know what to do with it. The nice thing about CAML is that it is already defined and baked into SharePoint. We will often use the Client Browser Tool http://spcb.codeplex.com to browse existing artifacts like Content Types to understand how to define Content Types from scratch. E.g.
Aside from configuration defined in XML we also simply drive configuration through PowerShell modules using the Client Object Model directly. Here is an example function for adding a Web:
At this point in time the Client Object Model does lack functionality when compared to its server-side counterpart. However, this is improving all the time with new methods being added in every release.
In some cases it is possible inspect the server-side object model using a tool like IL Spy http://ilspy.net and find (unsupported) ways to get the job done. For example we found a way to add links to the Search Center Navigation via this technique. I must stress that using an unsupported method should be for convenience only and you should have a backup plan should it fail. We normally write this backup plan into our deployment documentation and it’s usually just a manual way to achieve the same thing albeit more slowly.
I am now also seeing lots of discussion and examples around HTTP Remote operations to help fill the gaps in the Client Object Model. This is of course also unsupported but can be effective as a convenience and time-saver. We’ve used this effectively to map Search Crawled Properties to the Refinable Managed Properties in SharePoint Online. This is not supported by the Client Object Model and can take a huge amount of time so is ripe for automating. Here is a snippet showing how we call a function to update RefinableString00 with Crawled Properties:
In conclusion, automation using scripted deployment can be an extremely versatile and effective way to support your DevOps for SharePoint Online. At Perficient, SCRUM has proven to be a very effective methodology for SharePoint Online projects. Typically we are making the scripted deployment of any new feature part of the ‘Done Criteria’ for any development work. Scripting the deployment then very much becomes part of feature development and will be effectively tested in development environments before progressing to QA and Production.