Creating and deploying solutions to SharePoint Online and on-premises in a repeatable consistent manner can be a daunting task. There are a number of ways to develop against the different SharePoint deployments, and applying your customizations in a consistent and repeatable manner can be challenging. This is something we at Puzzlepart is tackling better with each project.

The (new) world of SharePoint development

tarjei_ormestoyl.jpgThe SharePoint world has changed a lot over the last few years. Gone are the days when developers, without hesitation, would use Visual Studio and farm solutions to solve any SharePoint requirement. A lot of new feasible development approaches have been introduced which should be considered by developers when customizing SharePoint and facing requirements.

The good, old SharePoint PowerShell setup scripts comes short facing the cloud, and although some PowerShell commands are available for SharePoint Online, it’s nowhere near the amount on-premises have. While there are workarounds, the deployment story still leaves some to be desired. The deployment process at a glance can seem manual and cumbersome, and without investing quite some resources into the thought process, there is a real risk that it can be.

Multiple deployment scenarios

Supporting both SharePoint Online and SharePoint 2013 on-premises installation of customization in an identical, repeatable process is almost required when your solution needs to support both platforms. Handling on-premises and online as two different platforms have a number of disadvantages. Development cost can increase if different tools and implementation techniques are used for each platform. Second, maintaining the solutions will be much more complicated, as the solutions will act differently as they are tightly coupled with the deployment platform. Third, the solutions will be much less portable, hindering migration to other environments or deployment platforms like the cloud. It is clear that tackling the deployment platforms in an identical manner is beneficial. An added bonus of having such mechanics in place, is that your solution supports more or less any kind of hybrid scenario as well.

Some community efforts exist that attempt to solve the challenge of deploying to SharePoint Online and SharePoint 2013. Many are preferring to use CSOM in PowerShell scripts, and some are quite feasible to use for some scenarios, like the Client Side SharePoint Powershell project at Codeplex. Even though they would support quite a few of our requirements, we’re not quite confident they support the kind of dual deployment scenario we are facing.

Are sandboxed solutions still viable?

There was a lot of discussion and confusion after Microsoft told the community erroneously that sandboxed solutions were deprecated a couple of years back. They soon corrected this to only hold true for sandboxed solutions with code. It would have been a little strange to deprecate something that they still use as part of core SharePoint functionality, for instance when exporting search settings or creating design packages.

Declarative sandboxed solutions can be quite powerful, as they can contain almost all types of SharePoint functionality used in a site. Building a sandboxed solution uses well-known SharePoint practices and it’s straight forward to create SharePoint features with artefacts like lists, libraries, search settings, display templates, page layouts, pages, CSS, JavaScript and master pages.

Even though sandboxed solutions helps us creating a lot of useful artefacts in SharePoint, we are still facing a number of challenges: How can the features be activated in a fixed order without going through the UI? How can fields and content types be provisioned when we know we shouldn’t do it declaratively?
How do we setup taxonomy at a global level, when a sandboxed solution is site collection scoped? How do we even upload the sandboxed solution to the site collection, without going through a manual UI process?

CSOM – A preferred approach

A tempting approach to these challenges we use here at Puzzlepart is the Client-Side Object Model (CSOM). One of the reasons we prefer this approach is that the CSOM code we write works more or less with both SharePoint Online and SharePoint 2013 on-premises. Coupled with the fact that you have the full power of Visual Studio to write C# code and you can use Sandboxed solutions to upload SharePoint artefacts, you have the power to create a repeatable deployment process for SharePoint online. While it’s also possible to use PowerShell and CSOM together, we feel that the code is much easier to maintain in a C# project than in PowerShell files.

Feasibility in the real world?

In a project we recently delivered for Asker Kommune, we faced the exact challenge discussed in this post. We had the requirement to create a solution that should be installed to and exist in both SharePoint Online and on-premises environments, while simultaneously be very simple to install. This gave us the opportunity to work on a deployment tool to setup SharePoint modifications via CSOM to support the different deployment scenarios. The tool is called Sherpa, and is available at Github​. Be sure to check it out, but keep in mind that this is work in progress and is subject to change without notice at a future time.

Here at Puzzlepart we’re all about SharePoint, and we’re constantly trying to figure out the best ways to tackle the SharePoint platform most efficiently, both in the cloud and on premises. Even though we see an increasing number of projects being realized in the cloud, some of our customers are still on-premises. Having deployment routines in place that can handle multiple scenarios is key to ensuring a consistent, repeatable deployment process.

Some of you are most likely facing some of the same challenges outlined in this blog post and we would very much like to hear from you to discuss the topic further. We can also help you if you need help in realizing your ideas on the SharePoint platform, whether it’s on-premises, hybrid or in the cloud.