Share point content and application lifecycle management guidance

S ae o t ot t
hrP i C n n&
n e
ATC NC L I P P R
E H IA WHT A E
E

A pctn icc
plao Leyl
i i f e
Maae et u ac
ngm nG i ne
d
Jrm Tae
ee y hk
S ae o t evr P
hrP i S r MV
n e

Tid cmet es u t a I Poes nl D vl esadohr tkh l r
h ou n st o to i T rf i a , ee pr n te s eo es
s d so s o , a d
rso s l frmaai teC net& A pc o Leyl wti Mioo ®
ep nie o
b ng g h o tn
n p la n icc i n c s
i f e h r
Saeo t b pee n meh d adrcmmed o s sflo ogn ao s
hrPi ® y rsn g to s n eo
n n a n ueu fr r i n
az
t i l n a cmpees e s aey frdvl i ad po n cd.
o mp met o rhni t tg o ee p g n rmo g o e
e v r on

So srd y
p noe b:

w wrpw b o
w . l e. m
ei c

SharePoint Content & Application Lifecycle Management Guidance

© Copyright RepliWeb, Inc. 2010. All rights reserved.

This guide contains proprietary information which is wholly owned by RepliWeb, Inc., and is protected by
copyright. No part of this guide may be reproduced or transmitted in any form or by any means (electronic or
mechanical, including photocopying and recording) without the written permission and consent of RepliWeb, Inc.

WARRANTY
The information contained in this document is subject to change without notice. RepliWeb, Inc. makes no
warranty of any kind with respect to this information, its accuracy or completeness. REPLIWEB, INC. SPECIFICALLY
DISCLAIMS THE IMPLIED WARRANTY OF THE MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
RepliWeb, Inc. shall not be liable for any direct, indirect, incidental, consequential, or any other damages alleged
in connection with the furnishing or use of this information.

TRADEMARKS
All trademarks and registered trademarks used in this guide are property of their respective owners.
Headquarters: 6441 Lyons Road, Coconut Creek, FL 33073
www.RepliWeb.com
e-mail: info@RepliWeb.com
U.S. and Canada: +1 954-946-2274
Europe: +44 208-544-8070
Please refer to our Web site for regional and international office information.

© Copyright RepliWeb, Inc. 2010. All rights reserved. Page |2


Introduction .................................................................................................................................................................. 4
SharePoint Assets ......................................................................................................................................................... 6
Issues with the Definition of Artefacts and Approaches .......................................................................................... 9
Architecture ................................................................................................................................................................ 10
Recommendations & Guidance .............................................................................................................................. 11
Team Development .................................................................................................................................................... 12
Development Environments ................................................................................................................................... 12
Solution Package Creation Tools ............................................................................................................................ 12
Common Issues ....................................................................................................................................................... 13
SharePoint ALM Maturity Model ................................................................................................................................ 20
Level 1 – Initial (Chaotic)......................................................................................................................................... 20
Level 2 – Repeatable ............................................................................................................................................... 21
Level 3 – Defined .................................................................................................................................................... 21
Level 4 – Managed .................................................................................................................................................. 22
Level 5 - Optimised ................................................................................................................................................. 22
Deployment Approaches ............................................................................................................................................ 23
Manual Deployments.............................................................................................................................................. 24
Backup/Restore and SQL Backup/Restore .............................................................................................................. 25
Export/Import ......................................................................................................................................................... 26
Content Deployment API ........................................................................................................................................ 27
Content Deployment Paths .................................................................................................................................... 28
Solution Packages ................................................................................................................................................... 29
Third Party Alternatives .......................................................................................................................................... 30
RepliWeb - ROSS ..................................................................................................................................................... 30
CodePlex Content Deployment Wizard Tool .......................................................................................................... 31
Summary: Recommendations & Guidance ................................................................................................................. 33
Assessment ............................................................................................................................................................. 33
Define acceptable approaches ............................................................................................................................... 33
About the Author ........................................................................................................................................................ 34
About RepliWeb, Inc. .................................................................................................................................................. 35
Bibliography ................................................................................................................................................................ 36



Introduction

The ever increasing demands from Organisations on their IT Departments have
required IT teams to be able to communicate their internal products and available
services with even greater efficiency and to attempt to create a competitive
advantage through technology. Key areas that Organisations focus on are
“Content management, Internet, Extranet and Intranet sites that allow them to communicate information
or CM, is a set of and manage internal and external business processes by capturing digital
processes and information within an Enterprise Content Management System (ECMS).
technologies that
support the The ability for SharePoint to support multiple projects and multiple Organisations
evolutionary life cycle of within one SharePoint Farm has resulted in a huge adoption rate and is
digital information. Microsoft’s fastest selling server product in its history (1). The SharePoint
This digital information Platform is considered the next logical step forward because it allows
is often referred to as Organisations to leverage and reuse common framework patterns developed by
content or, to be Microsoft rather than develop their own from the ground up. This advantage
precise, digital content. allows IT teams to maximise productivity and focus on implementing the business
Digital content may
functionality requirements rather than the framework itself.
take the form of text,
such as documents,
Applications have often been built on a bespoke basis, using ASP.NET and SQL
multimedia files, such
as audio or video files, technology stack, where the separation between the content and the system are
or any other file type easily defined by architectural layers and the roles that create them. SharePoint
which follows a content has blurred this separation as the same user interface is utilised by a range of
lifecycle which requires contributors including Solutions Architects, Developers, and Information workers.
management.”
Maintained solely by IT teams, traditional Applications typically followed a more
Wikipedia (1) structured software engineering process called the Waterfall Methodology. As
SharePoint has directly empowered common Information Workers, control of the
Systems has left the hands of the IT team and moved into a default ungoverned
state of typically untrained individuals. There are often multiple approaches to an
implementation that generally depend on the skill set and tools available to the
implementer, which in turn may lead to different levels of maintainability,
supportability, upgradeability, and scalability.



When managing the Application Lifecycle, at the highest level, Organisations
should strive to fulfil these four critical requirements within team development
“Application Lifecycle (2):
Management is the
coordination of all
1. Isolation – the ability to develop applications without interfering with
aspects of software
other developers
engineering – including
the formulation and
2. Consistent Quality – errors and conflicts identified prior to code check-in
communication of
and only validated logic deployed to shared environments
business and technical
requirements, code
3. Automation – identify build, code quality, and functional breaks
design and architecture,
frequently without human action
project tracking, change
management, coding,
4. Reproducibility – the ability to reproduce a build based upon time or
testing, debugging, and
event and to fully reproduce any production application
release management –
by using tools that
facilitate and track
The main challenge of using the SharePoint Platform is often how an Organisation
collaboration among
governs both the Content Management and Application Lifecycle Management.
and within work
This White Paper will review the elements of the SharePoint Platform and explore
teams.”
a variety of methods available to manage the Content Management and
MSDN, Microsoft 2009 Application Lifecycle Management including a deep dive into the deployment
approaches to facilitate isolation, consistency and quality, automation, and
reproducibility needed by implementation teams.



SharePoint Assets

Before starting to discuss SharePoint in any detail, one must first understand
some key concepts related to common SharePoint assets. The hierarchy of
SharePoint underpins the scope of where artefacts are implemented and the
parent/child relationships between each element of SharePoint.

SharePoint Farm

SharePoint Web Applications

Site Collections (Blank Team Site, Publishing Site, Collaboration Site, etc.)

Top Level Site

Lists (Document Library, Picture Library, Custom List, etc.)

List Items (Pages, Documents, Picture, etc.)

An example scenario based on this hierarchy would be an HR Performance
Appraisal system where a Sub Site is created for the application
underneath the “Corporate” Top Level Site which sits in the “Intranet” Site
Collection. In the Sub Site there is a Document Library (List) based on a
schema, with a custom List View, in a List Definition that stores
Performance Appraisal Word Documents (List Items). Each layer of the
hierarchy is needed for the system to function properly.

These artefacts can be implemented via different approaches that often cause
confusion as to where best to create them.



The figure below illustrates the different locations within the SharePoint physical
infrastructure where artefacts can be located (this diagram is an extended version
of the MSDN diagram (3).

Farm or Web Application Scope Site Collection or Site Scope
GAC WEB APPLICATION DIRECTORIES
Authored Artefacts
Assemblies (Sites, Lists, Content Types, Site
(Web Parts, Event Web Application Columns, Web Parts, SPD
Receivers, Artefacts Workflows)
VS Workflows, (web.config)
Custom Fields)

Customized Authored Artefacts
Uncustomized Solution Artefacts Customize (unghosted)
SharePointRoot Folder (hive)

(ghosted) Master Pages, Page Layouts,
Master Pages, Page Layouts, Uncustomize Themes, CSS, List Views
Themes, CSS, List Views

File based definitions
(cannot be customized) Authored Content
Application Pages, Site (List Items – pages, documents,
Definitions, List Definitions, pictures, Artefact Security
Content Types, Site Columns Permissions)

Solution Artefacts
Authored Artefacts
(packaged using WSP & deployed to all server
(all contained in Content Database)
file systems in farm)

Solution Artefacts

Solution Artefacts are created by Developers and published into a SharePoint
Solution Package (WSP). Solution Artefacts are typically created using Visual
Studio but can also be handcrafted with the use of a text editor and makecab
where assemblies are not required to be compiled.
Once the WSP is added and deployed to a SharePoint Farm, the artefacts will be
stored on each server in the SharePoint Farm’s file system in various locations:
SharePoint Root folder (hive), Global Assembly Cache (GAC) and Web Application
Directories (typically within the inetpub folder).

An example Solution Artefact within the HR Performance Appraisal
scenario would be a Visual Studio Workflow that gets attached to a List
Definition deployed as part of a Site Template available for provisioning.



Authored Artefacts

The instances of Authored Artefacts are generally created by Site Administrators
or Site Designers within the web user interface or SharePoint Designer based on
Solution Artefacts.
Authored Artefacts are stored in the SharePoint Content Database. All elements
stored in the SharePoint Content Database are visible via the Virtual File System
methods such as the Web UI, SharePoint Designer, or open source tools such as
SharePoint Manager 2007.

An example of an Authored Artefact within the HR Performance Scenario
would be a List View Web Part with a custom View created using
SharePoint Designer to report on this week’s Performance Appraisals.

Customised Authored Artefacts

Instances of Authored Artefacts, which are direct references to a Solution
Artefact, can also be customised (unghosted), meaning that the definition of the
artefact moves from a reference to the SharePoint Farm file system to a modified
instance in the SharePoint Content Database. Any changes to the Solution
Artefact will not be reflected in the Customised Authored Artefact. A Customised
Authored Artefact can be reset back to an Authored Artefact restoring the
reference to the Solution Artefact on the SharePoint Farm file system.

An example of a Customised Authored Artefact within the HR Performance
Scenario would be a customisation to the Site Page that was provisioned
with the Site Template to modify the look and feel.

Authored Content

The Authored Content is created by the Content Authors within the Web User
Interface or Office Client Applications such as Word, Excel, InfoPath, Access or
SharePoint Designer. This content is also stored in the SharePoint Content
Databases.

An example of Authored Content within the HR Performance Scenario
would be a completed Performance Appraisal Word Document.



Issues with the Definition of Artefacts and Approaches

The many approaches available to create elements with SharePoint can often
result in a breakdown of Artefact management. The intended use of an Artefact
dictates the method by which it should be created. This matrix (4) below shows
which elements can be created by which method(s):

SharePoint Solution Object Central Manual Server
Artefact Web UI
Designer Packages Model Admin
STSADM
Changes

List Template     
List Instance    
List Item Instance    
Content Type    
Content Type on List Instance   
Site Column Definition    
Custom Field   
.NET Workflow  
Workflow on List Instance   
SPD Workflow on List Instance 
Event Receiver   
Event Receiver on List Instance  
Custom Action   
Delegate Control  
Site Collection Instance   

Real World Example It is not a case of ‘one approach fits all’ with each Application Implementation
scenario. Various factors exist which dictate the most appropriate approach
St. Jude Medical enables to create each Artefact.
content to be authored
directly in production,
For example, a Developer may wish to deploy an Event Receiver and
but artefacts are
Workflow. When these artefacts are built in a local environment, certain
developed in isolated
dependent assets (example: list and/or event receivers) must also exist and
environments, and then
be available for lookup. In this case, it makes sense to create these Artefacts
promoted into
in one approach rather than create the Event Receiver and Workflow as a
production to assure
Solution Package and the List from within Designer.
quality and continuity.
(59)



Architecture

Common Development Challenges

A large part of managing the Content and Application Lifecycle is providing for a
positive experience for end-users. To assure quality and consistent Production
environments, Organisations are encouraged to architect separate, dedicated
environments for Developing, Testing/UAT, Integration, Staging, and Production.
With SharePoint being no exception, this suggested architecture is common
across most all Development Platforms. The logic behind this proposed
architecture can be summarised by these points:

Application Development requires significant testing to verify proper
functionality. This testing cannot be done within Production environments as
it risks disrupting data and a positive end-user experience.

Knowing that Developers will not always produce proper code on the first
attempt, thorough QA cycles can result in multiple cross-environment
deployments. This multiple deployment scenario can cause unwanted
application outages due to the process of how Solution Packages (.WSPs) are
deployed and the common reset of the Internet Information Services (IIS).

To assure scalability, release cycles should include considerations for testing
application performance under proportionate load and large amounts of
data. Quality testing should verify that new code is compatible with
Applications that already exist in Production.

Debugging of code should be restricted to a non-Production environment so
as to avoid the potential for holding back end-user access and other requests
in the queue.

© Copyright RepliWeb, Inc. 2010. All rights reserved. P a g e | 10


Recommendations & Guidance

The diagram below illustrates the flow of deployments between each
environment. One should note the flow of deployments moving not only from
Development on through to Production, but also from Production back on
Community Survey through to Development (or similar). A common requirement is often for
Analysis Authored Artefacts and Content to be pulled back into Development
environments to aid in debugging issues and also for promoting Authored
Typically UAT/Test and Artefacts to Solution Artefacts for a more mature application lifecycle. This also
Pre-Prod allows for Development work and testing to be done against the latest instance of
environments Production.
matched Production,
the main reason for
other environments
not matching
Development VM Integration Farm Pre-Prod Farm Production Farm
production were
around the cost of the
hardware and
provisioning the Complete Web Front End Web Front End Web Front End
software. 78.3% of
respondents stated
that they had seen
benefits of matching Development VM Application Application Application
production.

Complete
Database Database Database



Team Development

Development Environments

Considerable efforts are required to maintain a SharePoint Development
Environment that is consistent with the Organisation’s Test and Production
Community Survey Farms. Unlike ASP.NET development where an “F5 debug” experience is available
Analysis within Visual Studio 2008 via Cassini Web Server, SharePoint must be run natively
on a Server operating system such as Windows Server 2008 with a SQL Server
Out of the respondents instance accessible. It is advised that each Developer have their own environment
62% of environments to allow isolation, which causes a large overhead on managing consistency of
had a UAT/Test configuration, artefacts and content between each of the environments.
environment and 73.6%
had individual This often requires powerful Workstation or Server Virtualisation technology;
Development Virtual standard company desktops are typically inadequate due to memory
Machines, but only 50% requirements. The SharePointDevWiki.com maintains updated documentation on
had a Shared the best ways to manage ‘Building a Development Environment’ (5).
Development
Solution Package Creation Tools
environment and 37.7%
had a Pre-Production
environment. The other hot debate around SharePoint Development Tools is the choices in
Solution Package (WSPs) creation tools. The SharePointDevWiki.com has a
comparison matrix (6) that discusses Microsoft Visual Studio Extensions for
Windows SharePoint Services (VSeWSS) and two open source implementations:
WSPBuilder, STSDev and SPVisualDev.



Common Issues

Gradual Updates

By design, SharePoint instances of Artefacts will not reflect changes made and
deployed. An example of this is a List Instance based on a List Template Solution
Artefact. An update to a View or extra Column in the Template will not be
reflected in the Instance. Once an Application has been implemented and
deployed into Production, updates for new functionality or maintenance fixes to
the application will be required. Once a solution is “live”, a secondary
environment to Production is required to develop and test the changes made so
there is no negative impact on the End Users. This means that once the changes
to the Application have been tested and approved for deployment to the
Production environment a gradual update is required to bring the v1.0 release in
Production to the v2.0 release.

Development VM v1.0

Production Farm

Production Farm

Development VM v2.0

Production Farm

A common problem within gradual updates is the lack of reproducibility; the WSP
deployment approaches used to release the initial v1.0 release cannot be used to
manage the gradual upgrade to the v2.0 release. This challenge is quite common



when updating existing Content Types (7) and .NET Workflow Foundation
instances. Changes are often easier to make directly in the Web UI rather than
going back to the original source Solution Artefact. This short-cut often leads to
Developers’ attitudes of “refactoring the source later”, which, in the real world,
rarely occurs.

Two Way Syncs

Often when upgrading existing Applications, the current Authored Content in the
Production Application needs to be moved back to a Developer Virtual Machine
or to a Test environment with live data to ensure the system handles all the
potential paths. This can be extremely difficult to manage via manual processes
between two environments based on the approaches identified later in this
document. Organisations may consider the use of third-party solutions to
automate the refresh of instances across environments.

Real world example: To assure the latest development work is accurate,
the Federal Group strives to keep staging and production environments
identical; this standard requires replication jobs across farms (insert
reference to interview).

Highly sensitive Site Collections and Sites

Artefacts MUST be run under the context of an account which has appropriate
SharePoint permissions to a Site Collection or Site. This intentional limitation can
create challenges around highly sensitive sites where Implementers’ do not have
permissions. With the separation of permissions in place, there is no substitute
for a judicious change control system with a formal approvals process. Should an
Organisation seek to accelerate release cycles, one should consider ROSS from
RepliWeb which allows for safe job delegation across users and environments.



Permission Configuration

Permissions can be applied at any level of the hierarchy and are designed to limit
or enable the functionality and privacy of Solutions. A common example is a
Human Resources Departments’ Performance Appraisal System that restricts
access to Sites based on security permissions. Organisations sometimes neglect
to configure permissions across environments due to substantial manual
processes required to maintain these settings.
Cross-environment permission settings can be simplified by leveraging
programmatic code in either C#/VB.NET console applications or PowerShell
scripts executed on the SharePoint Farm server where the COM object is
available. Security ‘permission’ and ‘modifiers’ may also be included/excluded as
part of ROSS jobs.

Configuration Management

Often there are changes required to environments, specifically around web.config
files for each Web Application in each server on the farm. Examples of changes
can be for environment configuration settings and sections required to activate
.NET 3.5 as it is not supported out of the box with SharePoint 2007. These
changes can be made as part of the Solution Package Deployment leveraging the
SPWebConfigModification class (8). This API functionality is often very complex to
compose; both Reza Alirezaei (9) and Keith Dahlby (10) cover this in detail.
Should an Administrator attempt to make manual changes to each Web Front-
End server in each farm, one risks inconsistent configurations. It is therefore
essential to enforce standards around an accepted process in order to avoid
inconsistencies in Application functionality which are often difficult to debug. The
SharePointDevWiki.com has a page that presents the different approaches to
storing Application Config Settings (11).

Troubleshooting

When managing deployments across farms, an Organisation is bound to
encounter errors. Native tools often produce vague exception messages, such as,
“Object reference not set to an instance to an object”, thereby leaving the
Administrator without sufficient information necessary to pinpoint the cause of
the error. Successful troubleshooting comes as a result of experience and a well-
trained eye. For starters, one should set the environment to show more explicit
errors by modifying the web.config file (12). One may also examine the ULS logs
found in the 12 Hive by default. Alternatively, to ease troubleshooting,
organisations may consider the use of third-party comparison tools which can
discover and graphically present known issues.



Re-parenting with Parent Dependencies

In order to stay within the recommended 100 GB capacity for a Content Database
(13), Organisations might face the requirement to re-parent existing Sites to
become Site Collections with their own dedicated Content Database. When
attempted manually, one must move the Site from the current parent location to
either a Root of a Site Collection or a new child instance of an existing Site. While
managing this change, one must keep in mind that Sites often have dependencies
on Artefacts from levels past their existing parent, thereby complicating this
process change. Third-party solutions exist which help ease data management
Community Survey and site re-parenting.
Analysis
Out of the respondents,
50% did not track CAML vs. Object Model
version management
within each farm and Like most things in the SharePoint Platform, there is more than one way to get at
34.5% deploy monthly the end result. A frequent conversation is had on the merits of using declarative
and 27.6% deploy CAML in Element Manifests to provision Artefacts versus using programmatic
weekly. object model code in Feature Receivers (14).

Workflow Version Management

When deploying Workflows across environments, organisations should avoid the
common temptation of redeploying the same DLL Assembly version over the
existing one. In cases where dependencies on Class Methods exist, this shortcut
can cause existing instances of the Workflow to break. To properly deploy
Workflows across environments, one should consider third-party solutions or
Community Survey
review a workaround documented by Daniel Herzog (15).
Analysis
66.7% use a SharePoint Code Access Security
Administrator for every
deployment with 25% In order to properly control ‘security’ within an environment, one should consider
relying on SharePoint locking down assemblies to access certain parts of the underlying SharePoint APIs
Developers. and .NET Framework. Although considered ‘difficult’ by some, this adjustment
should be simple to implement within the web.config files. MSDN introduces the
topic here (16) and Reza Alirezaei discusses examples on his blog (17).



Unit Testing

It is extremely difficult to Unit Test SharePoint implementations due to the
architecture of the SharePoint Object Model with internal classes and direct
dependencies on the Database layer. Unit Testing in the general development
space is still up for debate and especially so with SharePoint. There is a great
introduction page and web cast on the SharePointDevWiki.com which leverages
TypeMock Unit Testing Framework (18).

Automated UI Testing

Real World Example The SharePoint User Interface is based on the ASP.NET web platform and various
tools exist to automate UI Testing. Often this is extremely difficult to set up
St. Jude Medical initially due to the way that SharePoint controls have been implemented in the
maintains a formal out of the box master pages and page layouts where Control ID’s and post-backs
change control have been relied on heavily. Tools such as WATIN and Selenium will not record
process, where scripts without some customisation effort after the initial recording.
requests for updates
are submitted, then Release Management
reviewed in UAT, then
approved by a release Highly critical within the Lifecycle, Release Management is an area which some
manager (59) Organisations either overlook or neglect. Too often the processes around Release
Management are undefined or executed on an ad-hoc basis. Failure to formally
manage release cycles can result in environments without central controls and
auditing. It is essential that a Release/Build Manager is put in place as the
gatekeeper to all environments to document what released version is being
promoted into each Environment. In addition to a well-documented approach to
release management, organisations may also consider third-party management
tools.

Dependency on SharePoint Administrators

The deployment of updates (WSPs, content, other functional elements) across
and into Production environments should ideally be managed by an Administrator
Community Survey
with sufficient privileges. While it may be tempting to extend deployment
Analysis
privileges to Developers, Organisations should clearly separate the roles. Building
Out of the respondents, SharePoint Solution Packages as WSPs requires deployment to be executed on a
only 74% stored their server joined to the target SharePoint farm. This requires administrative remote
source code in Solution desktop access to the server and Organisations should have policies in place to
Packages for source ensure that Developers do not have access to configure deployments themselves.
control. This restriction, together with Change Control policies around deployment, places
dependencies on the SharePoint Administrators which can often been seen as a
bottle neck. This can lead to Artefacts being created as Content Artefacts instead
of Solution Artefacts.




Use Solution Artefacts in Solution Packages

Although ‘best practice’ guidelines often suggest that Solutions Artefacts should
be built using Visual Studio development tools, many organisations find this
approach to be difficult, thereby resorting to the common method of creating
these Artefacts directly within the User Interface. This short-cut, though
tempting at first, often results in duplicate efforts and a failure to user proper
source control.
To fully leverage the power of the deployment technology within SharePoint, one
must use Solution Packages (WSPs). The use of this method is especially
important in large SharePoint Farms where updates are required to the file
system of multiple Web Front-End Servers. The Solution Package method is also a
great way to encourage encapsulation of an application into a package that is
deployable to any SharePoint Farm.

Use Source Control

The use of Source Control enables a team to capture releases to each
environment, the history of changes throughout the lifecycle, and complex
branching in large isolated functionality sets. Visual Studio supports various
source control repositories allowing developers to seamlessly manage their files
from the safety of their everyday individual desktop environment.

Automated Builds

Once a mature Source Control system is in place, Organisations can then stand up
a Continuous Integration Server which can ultimately create builds, then
automatically deploy them to each environment as illustrated by the Patterns &
Practices Guide (19) diagram below:

Source Control Build / Continuous
System Integration Server

wsp

wsp wsp
Development Test Staging Production
Stand-Alone Functional &
Environment Integration Testing Content DB Content DB

Database copied for validating installation
(desired but optional)



This overall approach requires various environments:

Stand-alone SharePoint environments for development
The development environment allows developers to work in isolation on
Solution Artefacts to give them the freedom to perform debugging on code
and have a more streamlined and faster deployment process using developer
tools such as VSeWSS/WSPBuilder to circumvent deploying WSPs to see
results by deploying directly to 12 hive or GAC, etc.

Continuous Integration Server

The Build Server pulls down the source code for the Solution Artefacts from
source control and builds the SharePoint packages (WSP). It performs the unit
tests and has the ability to deploy the WSP to the other environments in
progressive order.

Test environment
The test environment allows for user acceptance testing, manual functional
testing, automated functional testing, system testing, security testing, and
performance testing. After the solution meets production standards, the
SharePoint solutions are deployed to the staging environment.

Staging environment
The Staging environment should closely resemble the production
environment in terms of topology, for example the number of servers in each
tier of the farm, with the intention to identify any potential deployment
issues.

Brian Jackett (20) and an MSDN article (21) also have some interesting discussion
on automated deployment.



SharePoint ALM Maturity Model

The relation between the approach taken and the maturity of your ALM process
are directly proportional. Hugo Esperanca’s blog post (22) mapped the Capability
Maturity Model (CMM) (23) (24) to the approaches taken by Organisations
around SharePoint Deployment. These key process areas are relevant no matter
the size of the Organisation and implementation team.

The tiers listed below attempt to describe five graduations of ALM maturity. :

Level 1 – Initial (Chaotic)

“It is characteristic of processes at this level to be (typically) un-documented and
in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled
and reactive manner by users or events. This provides a chaotic or unstable
environment for the processes.”

A typical Level 1 environment will have a Production environment and all
implementation work will occur in this. The majority of this work is un-
documented and evolved naturally over the history of the environment. Any
development work is usually deployed manually to the farm file system.



Level 2 – Repeatable

“At this level, it is characteristic that some processes are repeatable, possibly
with consistent results. Process discipline is unlikely to be rigorous, but where it
exists it may help to ensure that existing processes are maintained during times
of stress.”

At Level 2 there will be more than one environment which requires focused
discipline around deployment. Typically this is done using Authored Artefacts
rather than Solution Artefacts, and therefore, no developer source control tool is
required. This will allow for the process to be repeated in each environment for
each deployment, but can lead to excessive effort required as Applications grow
in complexity. Confidence in the dependencies required for each environment is
often lacking due to poor documentation and can raise the risk of Application
failure in deployments.

Key Process Areas

Requirements Management
Software Project Planning
Software Project Tracking & Oversight
Resource and Software Subcontract Management
Software Quality Assurance
Software Configuration Management

Level 3 – Defined

“At this level, it is characteristic sets of defined and documented standard
processes are established and subject to some degree of improvement over time.
These standard processes are in place (i.e., they are the AS-IS processes) and
used to establish consistency of process performance across the organisation.”

At this level, the implementation team is mature enough to understand and be
comfortable with using Solution Artefact approaches. Not all Artefacts are
implemented using Solution Artefacts, leaving a mix of Solution and Content
Artefacts. The deployment process is therefore somewhat streamlined; this in
turn means that source control captures the history of the Application.



Key Process Areas

Organisational Process Focus
Organisational Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews

Level 4 – Managed

“At this level, it is characteristic that, using process metrics, management can
effectively control the AS-IS process (e.g., for software development). In
particular, management can identify ways to adjust and adapt the process to
particular projects without measurable losses of quality or deviations from
specifications. Process Capability is established from this level.”

At this level, a well-defined process is in place for an entire Application release
cycle from ‘Requirements Gathering’ through to ‘go-live in the Production
environment’. Documented and managed change control processes are
introduced to enforce quality across each environment. The Development Team
has now mastered the use of Solution Artefacts to gradually update existing
implemented Applications in SharePoint.

Key Process Areas

Quantitative Process Management
Software Quality Management

Level 5 - Optimised

“At this level, focus shifts to continually improving process performance through
both incremental and innovative technological changes/improvements.”

At this level the deployment process is streamlined with automated deployments
which do not depend on Administrators to run manual deployments of WSP’s in
the environment. These deployments can be automatically triggered as part of
the change control process that is in place.

Key Process Areas

Defect Prevention
Technology Change Management
Process Change Management



Deployment Approaches

For those Organisations which choose to implement a multi-stage, multi-farm
architecture, considerations should be made to then properly manage the
replication and deployment of assets from one environment to the next. A
variety of methods are available, ranging from manual processes to native tools
to commercial solutions. Regardless of the chosen method, Organisations must
carefully strategise and plan deployments in order to assure successful outcomes.
When planning deployment strategies, Organisations should take into
consideration these common variables:

The need for sufficient IT Resources
The extent of manual processes and impact on IT Resources
The ability to make processes repeatable
Reliability of deployment method & option of rollback
Timeframes for Release Cycles
The ability to control deployment timeframes & scheduling
Reporting, Auditing, & Notifications
Proper ‘Change Management’
The ability to govern the process of updates across environments
Controlling & selecting which assets get deployed within which jobs
The ability to replicate full-site updates or incremental changes
Ability to centrally manage & audit deployment processes

This section explores the various methods available to manage updates across
environments. The pros and cons below have taken into account various opinions
from SharePoint MVPs: Chris O’Brien (25) (26) (27), Ben Curry (28) and Waldek
Mastykarz (29) and other strong SharePoint community members: Stefan Goßner
(30), Mark Rackley (31) (32), Tyler Butler (33) and Johnny Smith (34).



Manual Deployments

Known as ‘Manual Deployment’, this process requires direct manipulation of
artefacts in each unique SharePoint Farm environment. Manual Deployments
require that a:
SharePoint Administrator manually deploy the artefacts by copying files into
the 12 Hive location, Global Assembly Cache and Web Application Home
Directories on each server in the target SharePoint Farm

SharePoint Administrator/Designer with access to the SharePoint Site
Collection must manually create the authored artefacts

Pros

Minimal setup overhead compared to other approaches

Cons

Microsoft does not support Manual Deployment to the SharePoint Root
location. (35)

Reliant on manual steps which are typically undocumented and
supplemented with over-complicated batch scripts

Manual steps are often inefficient, error prone, and consume resources when
repeated in multiple environments.

Requires that the SharePoint Administrator has advanced understanding of
SharePoint Root, associated artefacts, and their interdependencies

Extremely time consuming, particularly when there are multiple servers in
one SharePoint Farm environment; for example, two web front end servers in
the presentation tier and an index server in the application tier

“For a long time, we tried moving content from one environment to
another in a manual fashion, but the process was quite ineffective,” says
Yuri Roldan, Manager of Integration Services for Baptist Health. “There
was a lot of tedious work involved, so we abandoned that and asked our
developers to test on the box where the Web programming was originally
done. That created new challenges such as memory issues or lack of the
right tools. The result is that it took us anywhere from a day to a week or
more to get content ready for SharePoint. It also took a lot of time to do
backup and restores of existing content. (36)



Backup/Restore and SQL Backup/Restore

This approach helps Administrators either (1) using Microsoft’s STSADM
commands to backup and restore and entire Content Database, or (2) manually
backing up and restoring the SQL Database.

Pros

Typically the SQL Database backups will be stored for a week on a drive
somewhere and these can be utilised to restore a recent snapshot of an
environment for development purposes.

Cons

The export package only includes the artefacts stored in the Content
Database and does not include artefacts stored on the SharePoint farm server
file system. Importing the package into a farm without all the dependent
artefacts will cause it to not function, for example, Event Receivers required
in the Global Assembly Cache.

Importing an exported Site Collection or Site into the environment will
overwrite all content.

As Site Collections grow in the way of Authored Content, the size of the
export packages grows and it takes exponentially longer to export.

Backups are manual in nature and consume IT resources.



Export/Import

This approach allows Administrators to use Microsoft’s STSADM commands to
export and import Site Collections and Sites.

Pros

Useful for re-parenting Sites

Cons

Granularity of export to Sites (Web) only

Object GUIDs not preserved

Alerts, Audit Trail, Recycle bin items, Security state, Workflow tasks/State are
not exported

Importing an exported Site Collection or Site into an environment will
overwrite whatever is already there.

(see cons for SQL backup/restore)



Content Deployment API

This approach leverages the underlying Content Deployment API (codenamed
PRIME). By leveraging the API directly, one gains greater control over the
deployment process.

Pros

Automatic inclusion of database dependencies e.g. fields, content types,
master pages

Provides granular control over what gets deployed, down to List Item level

Can preserve object GUIDs

Ability to select options for security, versioning, and user roles

Cons

API coding requires Development skills.

Can only deploy the artefacts stored in the Content Database and does not
include artefacts stored on the SharePoint farm server file system e.g.
Features and Solutions, Configuration information (such as web.config files)
or application data, File system modifications: CSS, definitions (custom list
and site templates) etc. (37)

Does not include all content e.g. Recycle Bin items and state, Alerts, Personal
Views, Autocopy references, Workflow instances and associations, Search
index and contents, Audit trail, Change log history, Check-in/check-out state,
Security state, Workflow tasks and state (37)

Requires patch level to be the same on each server

Requires both environments to be connected for automatic deployment

Disk space is required for storage of packages for extraction on target servers.

Blank site template should be used for destination site collection. (38)



Content Deployment Paths

This approach allows Administrators with access to Central Administration to
configure Content Deployment Paths. Each Path defines a source and target Site
Collection or Site, as well as the authentication details. Jobs can be scheduled so
that the administrator can dictate what content should be deployed and how
often.

Pros

Automatically transfers the deployment package to the target environment

Capable of moving entire Site Collections/Sites on a scheduled basis

Site Owners have some control over content deployment via ‘Quick Deploy’
function.

master pages (same as Content API)

Can preserve object GUIDs (same as Content API)

Cons

Only deploy the artefacts stored in the Content Database and does not
include artefacts stored on the SharePoint farm server file system (same as
Content API)

(same as Content API)

No differentiation between Authored Artefacts and Authored Content (same
as Content API)

Requires patch level to be the same on each server (same as Content API)

Disk space is required for storage of packages for extraction on target servers
(same as Content API).

Blank site template should be used for destination site collection (38) (same
as Content API).



Solution Packages

The Solution Package approach requires SharePoint Development skills in writing
XML and .NET code, compared to SharePoint Designer skills in the Web User
Interface or SharePoint Designer. Deploying the Solution Package (WSP) requires
the use of the STSADM tool to be run within the SharePoint Farm.

Pros

Ability to deploy Solution Artefacts only into an existing Site Collection with
Authored Artefacts and Authored Content. This is extremely useful for
Product Development and re-use across multiple client environments with
different domains.

Ability to automatically deploy artefacts to all server file systems consistently
in the SharePoint Farm. Any new servers joined to the farm will also be
provisioned to receive these updated artefacts.

Allows for inclusion in Continuous Integration process with fine grained
version control of Artefacts

In certain circumstances, it is the only supported way to implement solutions
e.g. Workflows, Event Receivers, Web Parts.

Enforces a standardised way for SharePoint Developers to work

Self-documenting

Cons

Developer is responsible for including dependencies with Solution Packages

No support for updating Content Types, List Definitions, Site Columns etc. via
declarative approach; they must be updated using programmatic API
approach.

Requires significantly more effort to develop these packages compared to
other approaches

Weak rollback capability



Third Party Alternatives

Several third-party solutions exist which address replication within SharePoint.
Feature sets and functionalities range from basic replication of standard content
to complete management layers designed to streamline the Content &
Application Lifecycle.

RepliWeb - ROSS

RepliWeb’s ROSS (RepliWeb Operations Suite for SharePoint) enables
organisations to effectively manage the Content and Application Lifecycles within
SharePoint by replicating solutions, functional elements, and associated content
in multi-stage (Development, Staging, Production) and multi-site (distributed)
environments. Recognised for its ability to accelerate deployment timelines,
Real World Example ROSS ensures production readiness of sites, and invokes ‘best practice’ for change
“With the manual control within SharePoint.
processes of the past, it
would take a week or Pros
more to move a simple
form from staging to Filters – apply granular include/exclude definitions across solutions, content,
production. With ROSS, artefacts, workflows, web parts, permissions, etc., down to file/item level or
we can accomplish this by Metadata or Content Type
same task within
Delegation – administrators can assign pre-configured jobs to non-privileged
minutes.” (36)
users (developers, content owners) to submit on-demand
Rollback – reverse deployment errors
Preview – graphically confirm proposed changes or modify before commit
Reporting – useful for troubleshooting and auditing/compliance
Scheduled Deployments – on-demand, time-based, triggered or ad-hoc
deployment options
Incremental Updates – identifies/transfers deltas only between environments
Agnostic to version – deploy artefacts and content from one farm to another
across different SharePoint versions or service packs
Re-parent Sites – manage data by promoting sites to site collections

Cons

Separately licensed solution
Requires installation of client on one Web Front End server in each
participating farm
.WSPs must be built prior to deployment via ROSS



CodePlex Content Deployment Wizard Tool

The Content Deployment Wizard Tool developed by Chris O’Brien (39) leverages
the Content Deployment API in a Windows Form application. It provides a visual
interface to execute Content Deployments without development knowledge of
the API.

Pros

Configurations can be saved and re-used at a later date.

No Development skills are required.

master pages (same as Content API)

Granular control down to List Item level on what gets deployed (same as
Content API)
Community Survey
Analysis
Can preserve object GUIDs (same as Content API)
Ability to select options for security, versioning and user roles (same as
42% require document
Content API)
approval to deploy
Solution Packages into
Production or make file Cons
server changes to a
Production farm. 50% of
these respondents did Open source project unsupported by Microsoft
not require approval for
UAT/Test deployments. Must manually run application in each environment to either export or
import

Requires patch level to be the same on each server (same as Content API)


Disk space is required for storage of packages for extraction on target servers




SharePoint Deployment is a common issue across implementation teams. These
issues will be reduced as tools and processes mature and are released into the
community. This document attempts to review considerations for managing the
Content and Application Lifecycles within SharePoint and provide guidance to
organisations seeking to improve processes.

Provided the multiple considerations presented in this paper, organisations are
encouraged to review known pros and cons and revise strategies for
implementation. Ultimately, there is no single correct approach to deployment
and each organisation needs to discuss the pros and cons of each method to
determine which standards fit best for a specific implementation, team skill set,
and budget.



Summary: Recommendations & Guidance

Assessment

It is recommended that an organisation’s current processes are assessed against
the SharePoint Capability Maturity Model with the intention of progressing within
this model over time. This gap analysis may also help to get the budget to
achieve some of these objectives. When executing this gap analysis, an
organisation should also project budget in order to achieve stated objectives.

Define acceptable approaches

Documenting standards around available and recommended approaches to
managing the Lifecycle will allow the reader to communicate strategies to
internal/external teams with the hope of enforcing a consistent approach to
implementations.



About the Author

Jeremy Thake is a Microsoft SharePoint Server MVP and Solution Architect based
in Perth, Western Australia. He founded the SharePointDevWiki.com and updates
his blog frequently located at wss.made4the.net. He is a prolific user of Twitter
and can be followed at @jthake, where he shares links discovered from around
the SharePoint community along with other #SharePoint tidbits.
Jeremy is a Microsoft Certified Trainer and trains Developers, IT Pros, and End
Users in SharePoint. He also has recently presented at Microsoft TechEd Australia
and at many user groups.



About RepliWeb, Inc.

RepliWeb develops application infrastructure software that governs and
automates critical lifecycle management processes within SharePoint, Web,
Application and B2B Collaboration environments. Over one thousand
organizations rely on RepliWeb to ensure information and application availability
throughout distributed IT environments.

About RepliWeb Operations Suite for SharePoint (ROSS)

ROSS enables organizations to more effectively manage Content and Application
Lifecycles within SharePoint, resulting in an acceleration of release cycles and a
reduction in administrative and operating expenses.

ROSS provides selective or comprehensive replication of functional elements and
content throughout multi-stage (Development, Staging, Production) and multi-
site (distributed) environments. ROSS manages the deployment / replication of
sites, site collections, content, solutions, workflows, structure, look & feel,
navigation, features, content types, etc. Recognized for its ability to accelerate
deployment timelines, ROSS ensures production readiness of sites and invokes
‘best practices’ for change control processes.

For more information:
Visit www.repliweb.com
Email: info@RepliWeb.com
U.S. and Canada: +1 954-946-2274
Europe: +44 208-544-8070
Please refer to our Web site for regional and international office information.



Bibliography
1. Microsoft. Sales of Microsoft Office SharePoint Server Break $800 Million. Microsoft. [Online] July 2007.
http://www.microsoft.com/Presspass/press/2007/jul07/07-26SPPT800MPR.mspx.
2. Maslowski, Brian. Application Lifecycle Management in SharePoint. SharePoint Saturday NY. [Online] Jul 2009.
http://www.sharepointsaturday.org/ny/meetings/65/ApplicationLifecycleManagementinSharePoint.aspx.
3. P&P SharePoint Guidance. Deploying and Upgrading Solutions. MSDN. [Online] http://msdn.microsoft.com/en-
us/library/dd206931.aspx.
4. SharePointDevWiki. SharePoint Implementation Approach Comparison Chart. SharePointDevWiki.com. [Online]
April 2009.
http://www.sharepointdevwiki.com/display/public/SharePoint+Implementation+Approach+Comparison+Chart.
5. SharePointDevWiki.com. Building a Development Environment. SharePointDevWiki.com. [Online] 08 2009.
http://www.sharepointdevwiki.com/display/public/Building+a+SharePoint+Development+Environment.
6. —. Solution package development tool comparisons. SharePointDevWiki.com. [Online] 08 2009.
http://sharepointdevwiki.com/display/public/Solution+package+development+tool+comparisons.
7. Hillier, Scot. Best Practices: Developing Content Types in SharePoint Server 2007 and Windows SharePoint
Services 3.0. MSDN. [Online] 2009, Jul. http://msdn.microsoft.com/en-us/library/ee330223.aspx.
8. Microsoft. SPWebConfigModification Class (Microsoft.SharePoint.Administration). MSDN. [Online]
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx.
9. Alirezaei, Reza. SPWebConfigModification’s Top 6 Issues. Reza Alirezaei’s Blog. [Online] Jan 2008.
http://blogs.devhorizon.com/reza/?p=459.
10. Dahlby, Keith. SPWebConfigModification Works Fine. Keith Dahlby's blog . [Online] May 2009.
http://solutionizing.net/2009/05/26/spwebconfigmodification-works-fine/.
11. SharePointDevWiki.com. Environment Configuration approaches. SharePointDevWiki.com. [Online] Jun 2009.
http://www.sharepointdevwiki.com/display/public/Environment+Configuration+approaches.
12. SharepointDevWiki.com. SharePoint Development Debugging. SharepointDevWiki.com. [Online] Jul 2009.
http://www.sharepointdevwiki.com/display/public/SharePoint+Development+Debugging.
13. Thake, Jeremy. #SHAREPOINT SITE COLLECTIONS AND 100GB CONTENT DATABASE GUIDANCE. Jeremy Thake's
blog. [Online] Aug 2009. http://wss.made4the.net/archive/2009/08/14/sharepoint-site-collections-and-100gb-
content-database-guidance.aspx.
14. SharePointDevWiki.com. SharePoint Declarative (CAML) vs Programmatic (Object Model) Provisioning.
SharePointDevWiki.com. [Online] Sep 2009.
http://sharepointdevwiki.com/display/SharePointPlaybook/SharePoint+Declarative+%28CAML%29+vs+Imperativ
e+%28Object+Model%29+Provisioning.
15. Herzog, Daniel. Versioning in MOSS workflows. Daniel Herzog's Blog. [Online] Nov 2006.
https://blogs.pointbridge.com/Blogs/herzog_daniel/Pages/Post.aspx?_ID=4.
16. Microsoft. Securing Web Parts in Windows SharePoint Services. MSDN. [Online]
http://msdn.microsoft.com/en-us/library/cc768613.aspx.
17. Behind the Scences: CAS in Solution Packages. Reza Alirezaei's Blog. [Online] Dec 2008.
http://blogs.devhorizon.com/reza/?p=785.
18. SharePointDevWiki.com. SharePoint Development with Unit Testing. SharePointDevWiki.com. [Online] Jul
2009. http://www.sharepointdevwiki.com/display/public/SharePoint+Development+with+Unit+Testing.


Share point content and application lifecycle management guidance

Share point content and application lifecycle management guidance

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Share point content and application lifecycle management guidance

Ähnlich wie Share point content and application lifecycle management guidance (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Share point content and application lifecycle management guidance