SharePoint 2013 introduces new App Model for building customizations and extending the capabilities of the SharePoint platform. Did you know however that you could also leverage the new App Model in structured repeatable deployments?

Structured and repeatable deployments in SharePoint

SharePoint is a flexible platform that offers rich capabilities for building solutions. Using a number of different approaches you can build and deliver your solution to your users. Depending on the organization and the solution that you are building, there is a chance that it might be required of you to deploy your solution in different environments, such as UAT and Production, in an automated fashion in order to ensure its integrity and proper working. In such scenarios you will not only need to build your solution, but you will also need to take care for the installation and configuration process.

SharePoint solutions can be deployed in an automated fashion in a few different ways. For the last few years the most common approach was to build Farm Solutions that would consist of both the solution logic and the instructions for installation of the solution. The process of installing the solution package would be often scripted using PowerShell. This approach worked great for as long as you were working in an on-premises environment and were able to use Farm Solutions.

Leveraging the SharePoint 2013 App Model for structured and repeatable deployments

With the release of SharePoint 2013 and the shift towards the cloud more and more organizations are looking into leveraging the new App Model for building customizations for the SharePoint platform. The great thing about Apps for SharePoint is that they work both on-premises and in SharePoint Online allowing you to reuse your work no matter where your organization’s information is hosted. And although there are even more substantial differences in how structured and repeatable deployments are implemented in Apps for SharePoint and Farm Solutions, and it takes a moment to get used to, great results can be achieved using the new App Model.

Differences in using Farm Solutions and Apps for SharePoint for structured and repeatable deployments

Structured and repeatable deployments using Apps for SharePoint are different than using Farm Solutions. Following is an overview of the most important differences that you are very likely to encounter when switching to the new App Model.

Using Client-Side Object Model rather than the server-side API

One of the differences in how structured and repeatable deployments can be realized in Apps for SharePoint and Farm Solutions have to do with the fact the Apps for SharePoint are hosted outside of SharePoint and therefore use Client-Side Object Model (CSOM) rather than the server-side API. Because CSOM is executed remotely to SharePoint, it’s batched and the information is available only after specifically requested. In comparison when using server-side code all of the information was available to you immediately. CSOM allows you to write efficient code, requesting only the minimal set of information required for your app. To do so however, it requires discipline and consideration. Without it, there is a risk of you communicating with SharePoint too often requesting too much information, putting too much load on SharePoint, network and the server hosting your app.

Requesting App permissions

Another difference in implementing structured and repeatable deployments using Apps for SharePoint and Farm Solutions is that when using apps you need to request sufficient permissions for your app in order for it be able to complete the deployment process. In a way this resembles creating CAS policies for Farm Solutions with assemblies deployed to BIN. And although there are far fewer app permissions than CAS policies to choose from, you still have to know what app permissions are required for which operations in your deployment process. While it is possible to request Full Control over the tenant for your app and with that grant it access to all resources, it is far from a good practice and shouldn’t be used unless necessary.

Imperative deployments

When using Farm Solutions for structured and repeatable deployments the guideline was often to use declarative artifacts whenever possible and fall back to code if no declarative artifact was available for the particular piece of the deployment process. Over the years SharePoint developers got used to reading and understanding CAML and many found it easier to follow XML than configuration mixed with code written according to personal preferences of a particular developer.

Although you could provision quite a few things using declarative artifacts, SharePoint schemas didn’t cover all scenarios and code had to be used to fill the gaps. Depending on the contents of the solution this resulted in a mix of declarative artifacts and code making it sometimes challenging to keep track of what exactly is being deployed as a part of the solution. Frequent updates to the solution and the support for all the different upgrade paths added only more complexity to the mix. Additionally it turned out, that in some scenarios declarative artifacts would cause upgrading the SharePoint platform to fail.

When using Apps for SharePoint for structured and repeatable deployments the only approach at our disposal is to deploy configuration through code. Although this offers greater flexibility than using fixed declarative artifacts, it requires more responsibility. When writing code you have to ensure that it’s well structured and easy to understand both today and tomorrow. Additionally, as all of the deployment process is described in code, the code should also describe the update and retraction process, preferably to allow users to revert all changes done by the app to their original state.

State vs. process

In Farm Solutions declarative artifacts allowed you to describe the desired state of deployment for your solution. You could for example say: I want to deploy this particular List using this particular configuration, or I want to have a Web with this particular configuration. When using Apps for SharePoint configuration is deployed through code, which describes steps required to achieve the particular state rather than the state itself. In order to have a Web with a particular configuration you would need to check whether that Web already exists, you would create the Web, create Lists and Libraries, configure them, add Web Parts, etc. – all of which expressed in code line-by-line.

Verbosity

In structured and repeatable deployments using declarative artifacts the artifacts would describe a certain state. Getting to that state was implicitly done by SharePoint and we all assumed things would just work the way we intended. It was for example really easy to deploy a CSS file to a 5-level deep folder structure. Comparable, when using Apps for SharePoint and the imperative approach, you would need to manually check if each single level of the folder hierarchy existed, if the file itself existed and if so if it was checked out or not before deploying it. As you can imagine this requires more effort than simply saying: I want this file to be there. Do it.

Templates

Custom solutions often provided users with custom List and Web Templates – blueprints for quickly creating List and Webs with specific configuration. Unfortunately, after a while it turned out that using those declarative templates was not without a risk, particularly when upgrading SharePoint to newer versions.

Apps for SharePoint have been designed to isolate custom solutions from the platform and with that to decouple the platform from the solutions it hosts. As a result there is currently no way to create List or Web templates with Apps for SharePoint. Instead your app would provide user with some interface allowing her to create a preconfigured List or Web. Although there would be no difference between the List created using a template and the one created by the app from the end-user perspective, the List created by the app would have no reference to any declarative artifact making it more future-proof.

Is it worth it?

Implementing structured and repeatable deployment using the new App Model is different than using Farm Solutions with declarative artifacts. Using CSOM with its batching and demand-based access to information as well figuring out the right permissions for your app requires getting used to. Deploying artifacts programmatically isn’t always easier than using their declarative versions. In the end however any investment you will do in this area today will be absolutely worth it. The direction that Microsoft is heading with the SharePoint platform will require more and more experience with communicating with SharePoint remotely. Even though both Farm solutions and the new App Model are supported on-premises today, building future-proof solutions that work on-premises and on-line will require experience with leveraging the App Model.

Summary

SharePoint 2013 introduces new App Model for building customizations for the SharePoint platform. The App Model can also be leveraged for structured and repeatable deployments both on-premises and in the cloud. Although it’s different than its predecessors, it’s a powerful and flexible framework that can help you improve the quality of your SharePoint solutions. Because the new App Model works both on-premises and on-line it’s very interesting to learn and to benefit of as soon as possible.