Application Lifecycle Management in SharePoint 2013 : Planning your Customization Model and Release Packaging Approach (part 2) - Release Packaging Approach

2. Release Packaging Approach

Solution and apps packages are used to deploy and release customizations to your SharePoint 2013 farms. You should always package your code and other customizations in solution or app packages, and use them to deploy your customizations. In SharePoint 2013, you have three different kinds of solution packaging types that can be used: fully trusted solutions, user (sandboxed) solutions, and as an app. Each type has specific behaviors and implications.

Fully Trusted Solutions

As in SharePoint 2007 and 2010, SharePoint 2013 supports fully trusted solutions that can be deployed at the farm level to provide any customizations required for your projects.

Fully trusted solutions are deployed by adding them to the farm solution store located in the configuration database using Windows PowerShell. When the solution is available, it can be deployed to your farm.

Fully trusted solution customizations are deployed to the filesystem of each server and can be considered to be deployed at the farm level, not simply for an individual web application. The web application choice in Central Administration affects only which web.config files are actually updated based on the configurations defined in the solution package. This also means that when the solution package contains features, these features are visible in multiple web applications, which can lead to confusion.

The biggest advantage to using fully trusted solutions compared to deploying customizations manually is the automation of customization deployment. You can ensure that each server in your farm is a completely identical set of deployed customizations. Another advantage is that if you reinstall one of your servers or add a new server to your SharePoint farm, all customizations are automatically deployed, without any manual intervention.

One of the most important things to consider is that deployment or upgrade of a fully trusted solution requires downtime, as shown in Figure 2. This service break may not be long, but it can have an impact on users accessing the portal at the time the new package is deployed. This downtime is required to refresh the assembly from the IIS worker process, and, in practice, requires either an IIS reset or application pool recycle.

FIGURE 2

User (Sandboxed) Solutions

Sandboxed solutions, initially made available in SharePoint 2010, deploy customizations at the site-collection scope and safely execute customizations in a dedicated worker process. This enables a greater degree of flexibility when deploying small customizations and does not require an administrator to perform deployment on the server side.

Sandboxed solutions are deployed to a sandboxed solution gallery located in each site collection, and their usage can be monitored and controlled using an out-of-the-box monitoring system.

As shown in Figure 3, SharePoint 2013 imposes limitations on the types of solutions that can be created. This is to avoid code causing issues in the farm. Common usage scenarios include simple web parts and feature-based deployment of artifacts (such as master pages and page layouts). Sandboxed solutions are a great way to provide either department-level customizations or customizations to cloud-based environments such as Microsoft Online.

FIGURE 3

SharePoint 2013 Apps

Apps created using the new SharePoint app models are packaged in a file called *.APP. This file is composed of many of the files you see in a solution package, including the app manifest, SharePoint solution packages, custom actions and/or app parts, localization resource files, data tier application packages, web deploy packages, and any app office manifests.

When the app is ready, as shown in Figure 4, it can be published to the Microsoft Office Store or alternatively to your organization’s corporate catalog of SharePoint apps.

FIGURE 4

Design Practices

Because all SharePoint customizations are deployed using either solution packages or apps, planning your deployment is extremely important. A well-planned deployment provides flexibility for testing and reduces the impact on the costs of subsequent maintenance phases.

As discussed earlier in this section, one of the key considerations for the deployment architecture is the granularity of your customizations in each of the solution packages. Strike a balance between having too many solution packages versus placing all your customizations in one or two solution packages. Unnecessary regression testing is a waste of your budget, pushes out your timelines, and can be avoided. As shown in the real-world example, it is possible to structure your customizations into multiple solution packages based on their usage and functionalities. This structuring makes them easier to update.

Figure 5 shows a commonly used model, where features are divided based on their usage. As you can see, all commonly used features are placed in a common or shared solution package, and each keyfeature area has a dedicated package. This way, individual features (such as search or My Site) can be developed and tested without affecting other customizations.

FIGURE 5

One challenge with solution packages relates to shared resources between multiple packages — for example, third-party assemblies, utility classes, common base classes, or business logic layers. If two different solution packages deploy the same resource, and the second package is retracted from the SharePoint farm, the shared resources are retracted. SharePoint doesn’t track dependencies on individual artifacts and solutions.

This can be mitigated by using common or shared resources in a specific solution package. This way, all shared resources (such as third-party assemblies) are deployed centrally for the different services in the SharePoint farm.