After a customization has been
deployed to your SharePoint 2013 deployment, upgrade and patching
considerations come into effect. This section discusses strategies and
recommendations to upgrade customizations, and update sites, content,
and code in your SharePoint 2013 farms.
Upgrading Solutions and Features
SharePoint provides features for
solution and feature upgrade models that should be utilized in
customization projects. These make the versioning of the customizations
easier and remove the complexity required to modify existing sites.
The solution package manifest supports applying assembly redirections to the web.config
file of the web applications. This helps to make the required changes
to the applications, if assembly versioning is used as the versioning
model for code.
feature framework provides extensive
support for versioning features. This provides a method to update
existing sites. This can be used not only for updating customizations,
but also to manipulate content. There are a number of declarative and
imperative code options to upgrade features that are already activated
in various sites of your SharePoint 2013 farm.
From a development perspective, you should start
using the versioning option as soon as content creation starts,
especially when you can no longer delete and re-create site collections
and sites. After this key milestone, all new versions of the features
must be specifically planned, especially if any changes are required to
existing sites.
As previously mentioned, the new app model
provides extensive support for updating apps. The update process
facilitates two key scenarios. The first scenario is where you need to
update an existing App to add new functionality to fix a defect or
security issue. The second scenario relates to replacing and migrating
from an old app to an entirely new one.
Patching Your SharePoint 2013 Environment
Patching your production environments
can be complicated. From a code perspective, this is primarily limited
to how you deploy bug fixes to existing customizations and how new
customizations are deployed to your environment.
From a content and farm perspective, after your
initial code release and when production use begins, users create
content; set up and complete workflows; customize and configure sites,
lists, and items; fill in meta data based on existing content types;
create their own content types; and so forth. Your production
environment takes on a life of its own.
Patching
Patching of the code in SharePoint is
relatively easy and can be done by updating the solution package (which
already exists in the farm). From a code perspective, the only major
thing to remember in SharePoint 2013 is that if you have newer versions
of features developed, you must remember to increase the feature
version and provide the required definitions for the feature upgrade
actions.
When new versions of the feature are deployed as
part of a new solution package version, the features are not
automatically upgraded to the newest version. The feature framework
follows the same patching model as other SharePoint patching, in that
you can add newer versions of the definitions, but the upgrade doesn’t
have to be applied immediately.
The upgrade of feature definitions is performed either by using the PSConfig tool or by using SharePoint APIs, which provides more granular options for the upgrade. Running PSConfig
results in downtime for the whole farm, so upgrading using that method
is not always the best option. The SharePoint API can be used to
upgrade individual features in a site collection or in the whole farm,
and this approach doesn’t require any downtime.
Content
Patching
SharePoint content means patching or changing already provisioned sites
in a production environment. Changing content types of individual list
items can be a complex task and requires detailed planning. A content type
defines the data structure of an individual data object in SharePoint
2013 that is stored in a SharePoint content database. Modification to
existing content types should be carefully considered. SharePoint 2013
supports adding new fields to existing content types as part of the
feature framework upgrade functionality. But if you must change content
types of existing items, this must be developed as custom code or a
PowerShell extension.
Complicated scenarios exist in which code and
content updates need to be deployed to your production environment at
the same time. For example, an upgraded site definition may now include
a new site collection scoped feature. For new sites, this isn’t a
problem because the updated site definition activates the feature
automatically. However, if the business requires the feature in
existing sites, this requires code to activate the feature based on a
specific site definition. These types of updates require careful
planning to coordinate content or code changes across your farm.
Another example that may require an update to a
content type is a base business document type, specifically developed
for a business, which is already in use in all sites in production. If
the update requires new fields, and moving content between fields, this
requires code to update each item that uses the outdated field.
In these scenarios, IT professionals typically request a custom PowerShell extension or custom feature to perform these operations.
The recommended option is to use the new feature
upgrade options, which can also provide support for feature versioning
for existing sites. You can use this functionality to modify site
structures and content in structured ways without any custom
methodology, which would cause project-specific processes to be
created. A feature framework versioning model can be also extended by
using custom code to fulfill additional capabilities.
Other content considerations may also include the
existence of different lists and web parts on sites. These can be
relatively easily modified using the new feature framework upgrade
functionality, which provides the capability to execute any custom code
as part of the feature upgrade. This custom code can be then developed
to do required changes for the existing structures based on new
requirements.
In the following section you concentrate more on practical considerations for your development team planning.
