Application Lifecycle Management in SharePoint 2013 : Planning your Key Development Phases and Release Model (part 2) - Release Models

2. Release Models

The release model can be described as the process and flow from development to your production environment and includes implementation and maintenance time. It also includes the planning of the processes for maintenance of the servers and software, not just the flow of the customizations, solution packages, and apps.

This section examines several release models, including the following:

• Direct release
• Phased release
• Rolling release

Direct Release Model

One of the models used to ensure flexible SharePoint usage is to use SharePoint Designer in the production environment to customize the portal behavior based on business requirements. The direct release model requires one client environment and your production environment. This approach carries a higher risk of causing issues to end users in your production environment because changes made may impact end-user productivity.

Even though SharePoint Designer provides the flexibility to customize your environment, it may still require some custom code or XML configurations. This would require separate environments to ensure that SharePoint Designer customizations don’t break anything in already-deployed customizations. There is no way of recording the SharePoint Designer customizations to enable you to apply them to multiple site collections. For example, if you have hundreds of different collaboration sites, this model is definitely not the most cost-efficient and is, therefore, not recommended.

Interestingly, sandboxed solutions and apps also fall under the direct release model. Site owners can upload a sandboxed solution to the User Solution gallery and can add an app from the corporate app catalog or, if it has been enabled, from the Microsoft Office Store catalog.

The risk of sandboxed solutions and apps causing catastrophic issues is greatly reduced. Speaking frankly and honestly, although it is highly unlike that these two solution models will result in downtime of your SharePoint 2013 farm, they may result in downtime of a critical site that is key and central to all users in your SharePoint 2013 farm. The key issue here is that a layer of governance is required to protect critical sites from apps and sandboxed solutions that have not been developed and tested to the same exacting standards of the core customizations in your SharePoint 2013 environments. Where feasible, do not directly release to a critical site. Always test your sandboxed solution or app in your quality assurance environments.

A final consideration, when consuming apps from the Microsoft Office App Store, is the dependence created on an external or third-party app developer to respond, in a timely manner, to produce updates for issues reported with their app. It is this loss of control to respond timely that degrade the end-user experience of carefully thought-out SharePoint 2013 deployments.

Phased or Gated Release Model

The phased release model (shown in Figure 3) uses separate environments for different phases of the project and incorporates clear decision criteria, which are essentially phases or “gates” that control how releases progress through your environments. Various criteria must be met before a release can proceed through a gate. This model is the most commonly used model in the SharePoint 2007 and 2010 environments because it provides the most opportunity for your operations and governance teams to pick up any issues before the release is installed in production environments.

FIGURE 3

Figure 3 includes the following numbered tasks:

The biggest challenge in the phased or gated release model is to keep the preproduction environment up to date with the production environment updates. This model requires following a process as strictly as possible, and all configurations are first tested in preproduction.

Quite often the preproduction user acceptance test (UAT) and testing (QA) farm do not mimic the production environment infrastructure. This makes it difficult to truly verify the deployment actions against production configurations of existing sites and customizations. Although developers may have superhero powers, they still rely on integration, smoke testing, and user acceptance testing of their software release against existing sites that may be touched by the release. It doesn’t need to be all sites, but a good representative sample of sites that will be affected by the software release. This requires a well-maintained and regularly refreshed QA, UAT, and preproduction environment.

Rolling Release Model

The rolling release model (shown in Figure 4) uses two primary environments in turn for production and QA environments. This model provides extreme flexibility and increases the overall quality of the released iterations. Basically, the development is phased similarly as with a fully phased model, but the QA and production environments switch their roles during each release.

FIGURE 4

Figure 4 includes the following numbered tasks:

Before customizations are deployed to the preproduction environment, content databases are copied from the production environment so that initial deployment actions can be verified. Final acceptance testing (which optionally includes load testing) can be conducted in the preproduction environment before the decision is made to move to production. For most flexible deployments, these environments should be virtualized so that you can easily increase hardware if new customizations have some additional requirements.

The switch between the environments is done at the load-balancer or DNS level. Before it’s done, content databases in the current production environment are set to read-only mode, which disables all editing options from the SharePoint 2013 UI. (For example, Ribbon buttons are disabled and grayed out.) The portal behaves otherwise as planned, but there’s no way to add any new content. Afterward, the content databases of the currently used production environment are copied one more time to the preproduction environment. When all required databases are available, traffic is switched between the environments from the network load balancer, and the roles of the environments are switched.

The rolling release model decreases downtime required for the releases and ensures that there’s also a backup environment available if something critical happens on the farm (which is acting as the primary farm at the particular time). This not only improves the release model of the customizations, but also helps to minimize downtime during patching of the operating system and SharePoint 2013.

The rolling release model has obvious advantages with the SharePoint deployment. In many enterprise projects, there’s a specific dedicated preproduction or QA environment, which mimics the production environment. Using the rolling release model, this environment and the investments done for the deployment are utilized more efficiently. In cases in which the production environments are virtualized, you can more efficiently use the virtualization platform to provide flexibility between the environments, meaning that you can definitely scale down the hardware capacity of the current preproduction or QA environment and scale up just before the traffic is switched again.

The rolling release model increases the availability of the services because when using this model, no service breaks are required during customization deployment, SharePoint patching, or even operating system patching. Depending on the virtualization platform architecture, the patching of the virtualized hosts may not even cause service downtime. Using Windows PowerShell, you could relatively easily automate the whole process of getting databases between environments and deploying customizations to a farm.