If you are an experienced SharePoint developer, you’ve probably created a lot of code to deploy and upgrade SharePoint solutions. Back in SharePoint 2007, there was zero guidance how to do this, so everyone created their own scripts to deploy WSP’s, create sites, etc. ┬áThis has caused a lot of headaches and frustration, probably one of the reasons why SharePoint is the most dreaded development platform according to Stackoverflow.

Farm solutions are still out there, but since I’ve learnt about SPMeta2 I’ve moved away from farm solutions where possible. And, SPMeta2 is now even more awesome, with incremental support!

The problem with farm solutions always has been upgrading of existing sites. Many of my legacy scripts contained code to re-create site collections, as that was the easiest way to deploy your changes. But, when your solution was in production, this was of course not an option.

I’ve created a lot of console applications, Powershell scripts, etc. to upgrade site collections and e.g. add a new site column. In SharePoint 2010, feature versioning was introduced, but that still required custom Powershell and was not very robust.

Then I learned about SPMeta2 which solves all these issues! Instead of elements/feature XML, you define your customizations in C#. Using some C# code you deploy this to your SharePoint sites. And the great thing is that your definitions and models are platform agnostic. It’s very easy to move from SharePoint 2013 on premises with SSOM to Office 365 with CSOM; the only changes required are a couple of lines of code to use a different provisioning service.

There was one issue with SPMeta2: Deployments could take a lot of time. Every time you ran a deployment, it would update everything in SharePoint according to the definitions. Even if nothing had changed, which can take quite some time. Especially content type updates are slow (which is not really a SPMeta2 problem of course). Then, after raising this on Github, the amazing support team behind SPMeta2 stepped in and implemented incremental support for SPMeta2.

Incremental support in SPMeta2 can decrease your deployment time by over 80%

What this does, is that it hashes the definitions, and compares that with the stored hash in the SharePoint site. If they are the same, SPMeta2 knows that nothing has changed, and will skip that step. In my local deployment I’ve seen performance improvements of 80% for subsequent deployments. Of course, a first deployment will not be faster, but this makes developing a lot easier.

This hashing works very smart, e.g. it will detect changes in your model, but also in deployed artifacts. As with all code in SPMeta2, this is probably the highest quality code I’ve seen in any project. Everything is covered by unit / integration tests, so the change for bugs is extremely low.

Before this incremental support we commented out parts of the model during development, which is of course risky.

Thanks SPMeta2 for implementing this feature!

The documentation is not ready yet, see the Github issue for instructions.