One of the most important
(and, unfortunately, often overlooked) areas to consider in SharePoint
deployments is the detailed planning of your development phases and the
release model required to support each of these key phases.
This section discusses the key development phases
and takes an in-depth look into the common releases used in SharePoint
projects.
1. Key Development Phases
Most, if not all, SharePoint projects can be divided into three key stages:
- Initial iterations — New code
project, developed over a series of sprints or iterations, that
culminates in working software ready to be released to quality
assurance environments.
- Content creation starts — Working
(quality-assured) software is released to production environments and
is available to site owners and content authors to begin using. Site
and content preparation can now begin.
- Release models after production use starts
— Software has been configured by site owners and content authors have
finished creating the initial content. End users are now using the site
(and working software) in production. Any software updates must be
carefully planned and tested against copies of production data.
Now look at each of these key development phases in more detail.
Initial Iterations
The development phase will be divided
into a number of iterations or subphases, regardless of the development
methodology used in the project. This way, you can more easily plan the
tasks based on priorities and follow up on development progress.
New SharePoint projects tend to start with a
proof of concept (POC) to ascertain the feasibility and suitability of
using SharePoint 2013. When projects progress to the next stage, the
POC is often used as a starting point and code for your project team.
The quality of most POCs is not adequate to directly continue to
development. You must start discussions with the customer to ensure
that the development assumptions and requirements gathered to this
point are correct. This can ensure that the implementation moves in the
right direction.
Most project teams prefer detailed technical
specifications to be in place before code is developed. This is a
difficult challenge to tackle up front in complex developments and
requires a waterfall approach to development. More often than not,
especially if your customer is not familiar with SharePoint, the
customer knows only what he or she wants when he or she sees it. Using
an Agile-based development methodology and philosophy helps to balance
the amount of documentation required in the initial iteration.
NOTE Regardless
of your methodology, always document your requirements and use cases.
Failure to do this makes it harder for your development to estimate
work effort, harder for your test team to produce test cases, and
easier for your customer to scope-creep, and therefore harder for you
to estimate the impact of additional effort required. Yeah,
documentation is painful exercise, but it is this documentation that
can help you get a sign-off from the customer.
Another important consideration is the design of
your Visual Studio project and code structure. Visual Studio structure
defines solution names, features, and their behaviors. Take the time to
design a proper Visual Studio structure because this can save rework
and development effort later in the project.
Assuming that your Visual Studio code and project
structure are planned and available, the developer can start
implementation. This means that each of the web part classes and all
feature definitions have been created based on the specification, but
actual business code from the classes is missing. This way, you avoid
issues in the structure deployment caused by changed feature
associations or new solution packages.
Figure 1 demonstrates common development stages.
Content Creation Starts
One of the most important and critical
milestones in a SharePoint project is when content creation starts.
From this phase forward, daily or weekly builds cannot just re-create
the site collection using scripts. You must start using an upgrade
model to your environment because you don’t want to lose content that
the content editors have already created.
An important consideration related to content
creation is deciding on and finalizing the data structure (for example,
site columns and content types) of your deployment. Although these can
be changed after the initial release, their update requires additional
work and potential content patching to ensure no content is lost.
Whenever content creation starts, the development
model must be switched to a maintenance-and-upgrade model. For smaller
projects with few customizations, this is not a difficult change. But
if a solution consists of numerous site definitions or web templates,
the change is much more dramatic and must be carefully planned.
Release Models After Production Use Starts
When production use starts, you have
additional considerations. All changes to your code base must be
evaluated so that they don’t cause any issues with the already deployed
features. Therefore, your production upgrade model should be carefully
planned.
Similar to SharePoint 2007 and 2010, downtime is
required when new full-trust solutions are deployed to SharePoint 2013.
If you use the rolling release life-cycle model, a service break is not
required. User (sandboxed) solutions can be updated without requiring a
service break, as long as the interfaces and features do not change too
much. SharePoint apps do not require server downtime but are
temporarily unavailable to end users while they are updated. See the
MSDN app for SharePoint update process at http://msdn.microsoft.com/en-us/library/fp179904(v=office.15).aspx.
The most important consideration when releasing
new customizations is to ensure that a proper rollback strategy is
available. Although SharePoint 2013 does not provide built-in, rollback
functionality for farm or sandboxed solution package deployment
failures, the new app model does provide extensive update and rollback
support. For more information on the app update process, see the MSDN
app for SharePoint update process article at http://msdn.microsoft.com/en-us/library/fp179904.aspx.
In the case of failed farm and sandboxed solution
deployments, depending on the issue encountered, either redeploying a
previous version of the solution or restoring database backups are the
only solutions to move forward.
NOTE Remember
that if there’s a need to restore database backups, both configuration
and content databases must be restored. This is because the solution
store for full-trust solutions is located in the configuration
database. It’s also important to synchronize the files in the
filesystem because a full-trust solution is extracted to each of the
servers in the farm. User (sandboxed) solutions are stored only in the
content database, so their restoration is straightforward.
Because there are many considerations for the
maintenance phase deployments, a detailed road map and process for the
upgrades should be created. This is quite common for larger projects
that release new versions of your customizations after the initial
release.
Figure 2 shows a deployment plan where, after the initial release, deployments are done on a quarterly basis.
