Transcript
Page 1: Share point content and application lifecycle management guidance

www.repliweb.com

SharePoint Server MVP Jeremy Thake

This document sets out to aid IT Professionals, Developers, and other stakeholdersresponsible for managing the Content & Applicaon Lifecycle within Microso® SharePoint® by presenng methods and recommendaons useful for organizaonsto implement a comprehensive strategy for developing and promong code.

Sponsored by:

A TECHNICAL WHITE PAPER SharePoint Content &

Application LifecycleManagement Guidance

Page 2: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

© 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: [email protected] 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.

Page 3: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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

Recommendations & Guidance .............................................................................................................................. 18

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

Recommendations & Guidance .............................................................................................................................. 32

Summary: Recommendations & Guidance ................................................................................................................. 33

Assessment ............................................................................................................................................................. 33

Define acceptable approaches ............................................................................................................................... 33

About the Author ........................................................................................................................................................ 34

About RepliWeb, Inc. .................................................................................................................................................. 35

Bibliography ................................................................................................................................................................ 36

Page 4: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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 Internet, Extranet and Intranet sites that allow them to communicate information and manage internal and external business processes by capturing digital information within an Enterprise Content Management System (ECMS). The ability for SharePoint to support multiple projects and multiple Organisations within one SharePoint Farm has resulted in a huge adoption rate and is Microsoft’s fastest selling server product in its history (1). The SharePoint Platform is considered the next logical step forward because it allows Organisations to leverage and reuse common framework patterns developed by Microsoft rather than develop their own from the ground up. This advantage allows IT teams to maximise productivity and focus on implementing the business functionality requirements rather than the framework itself. Applications have often been built on a bespoke basis, using ASP.NET and SQL technology stack, where the separation between the content and the system are easily defined by architectural layers and the roles that create them. SharePoint has blurred this separation as the same user interface is utilised by a range of contributors including Solutions Architects, Developers, and Information workers. Maintained solely by IT teams, traditional Applications typically followed a more 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.

“Content management, or CM, is a set of processes and technologies that support the evolutionary life cycle of digital information. This digital information is often referred to as content or, to be precise, digital content. Digital content may take the form of text, such as documents, multimedia files, such as audio or video files, or any other file type which follows a content lifecycle which requires management.” Wikipedia (1)

Page 5: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

When managing the Application Lifecycle, at the highest level, Organisations should strive to fulfil these four critical requirements within team development (2):

1. Isolation – the ability to develop applications without interfering with other developers

2. Consistent Quality – errors and conflicts identified prior to code check-in and only validated logic deployed to shared environments

3. Automation – identify build, code quality, and functional breaks frequently without human action

4. Reproducibility – the ability to reproduce a build based upon time or event and to fully reproduce any production application

The main challenge of using the SharePoint Platform is often how an Organisation governs both the Content Management and Application Lifecycle Management. This White Paper will review the elements of the SharePoint Platform and explore a variety of methods available to manage the Content Management and Application Lifecycle Management including a deep dive into the deployment approaches to facilitate isolation, consistency and quality, automation, and reproducibility needed by implementation teams.

“Application Lifecycle Management is the coordination of all aspects of software engineering – including the formulation and communication of business and technical requirements, code design and architecture, project tracking, change management, coding, testing, debugging, and release management – by using tools that facilitate and track collaboration among and within work teams.”

MSDN, Microsoft 2009

Page 6: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

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.

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

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

Top Level Site

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

SharePoint Web Applications

SharePoint Farm

Page 7: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

Solution Artefacts(packaged using WSP & deployed to all server

file systems in farm)

Authored Artefacts(all contained in Content Database)

Authored Artefacts(Sites, Lists, Content Types, Site

Columns, Web Parts, SPD Workflows)

Authored Content(List Items – pages, documents,

pictures, Artefact Security Permissions)

Customized Authored Artefacts(unghosted)

Master Pages, Page Layouts, Themes, CSS, List Views

Farm or Web Application Scope Site Collection or Site Scope

Web Application Artefacts

(web.config)

Uncustomized Solution Artefacts(ghosted)

Master Pages, Page Layouts, Themes, CSS, List Views

Uncustomize

Customize

File based definitions(cannot be customized)Application Pages, Site

Definitions, List Definitions, Content Types, Site Columns

Share

Po

intR

oo

t Fold

er (h

ive)

Assemblies(Web Parts, Event

Receivers, VS Workflows, Custom Fields)

WEB APPLICATION DIRECTORIESGAC

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).

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.

Page 8: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 9: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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):

Artefact Web UI SharePoint

Designer Solution Packages

Object Model

Central Admin

STSADM Manual Server

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

It is not a case of ‘one approach fits all’ with each Application Implementation scenario. Various factors exist which dictate the most appropriate approach to create each Artefact.

For example, a Developer may wish to deploy an Event Receiver and Workflow. When these artefacts are built in a local environment, certain dependent assets (example: list and/or event receivers) must also exist and be available for lookup. In this case, it makes sense to create these Artefacts in one approach rather than create the Event Receiver and Workflow as a Solution Package and the List from within Designer.

Real World Example St. Jude Medical enables content to be authored directly in production, but artefacts are developed in isolated environments, and then promoted into production to assure quality and continuity. (59)

Page 10: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 11: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

Community Survey Analysis

Typically UAT/Test and Pre-Prod environments matched Production, the main reason for other environments not matching production were around the cost of the hardware and provisioning the software. 78.3% of respondents stated that they had seen benefits of matching production.

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 through to Development (or similar). A common requirement is often for Authored Artefacts and Content to be pulled back into Development environments to aid in debugging issues and also for promoting Authored Artefacts to Solution Artefacts for a more mature application lifecycle. This also allows for Development work and testing to be done against the latest instance of Production.

Production Farm

Web Front End

Database

Application

Web Front End

Database

Application

Web Front End

Database

Application

Complete

Integration Farm Pre-Prod FarmDevelopment VM

Complete

Development VM

Page 12: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

Community Survey Analysis

Out of the respondents 62% of environments had a UAT/Test environment and 73.6% had individual Development Virtual Machines, but only 50% had a Shared Development environment and 37.7% had a Pre-Production environment.

Team Development

Development Environments

Considerable efforts are required to maintain a SharePoint Development Environment that is consistent with the Organisation’s Test and Production Farms. Unlike ASP.NET development where an “F5 debug” experience is available 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 instance accessible. It is advised that each Developer have their own environment to allow isolation, which causes a large overhead on managing consistency of configuration, artefacts and content between each of the environments.

This often requires powerful Workstation or Server Virtualisation technology; standard company desktops are typically inadequate due to memory requirements. The SharePointDevWiki.com maintains updated documentation on the best ways to manage ‘Building a Development Environment’ (5).

Solution Package Creation Tools

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.

Page 13: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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

Production Farm

Development VM v2.0

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

Page 14: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 15: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 16: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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 and site re-parenting.

CAML vs. Object Model

Like most things in the SharePoint Platform, there is more than one way to get at the end result. A frequent conversation is had on the merits of using declarative CAML in Element Manifests to provision Artefacts versus using programmatic 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 review a workaround documented by Daniel Herzog (15).

Code Access Security

In order to properly control ‘security’ within an environment, one should consider locking down assemblies to access certain parts of the underlying SharePoint APIs 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).

Community Survey Analysis

Out of the respondents, 66.7% use a SharePoint Administrator for every deployment with 25% relying on SharePoint Developers.

Community Survey Analysis

Out of the respondents, 50% did not track version management within each farm and 34.5% deploy monthly and 27.6% deploy weekly.

Page 17: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

© Copyright RepliWeb, Inc. 2010. All rights reserved. P a g e | 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

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 initially due to the way that SharePoint controls have been implemented in the out of the box master pages and page layouts where Control ID’s and post-backs have been relied on heavily. Tools such as WATIN and Selenium will not record scripts without some customisation effort after the initial recording.

Release Management

Highly critical within the Lifecycle, Release Management is an area which some 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 with sufficient privileges. While it may be tempting to extend deployment privileges to Developers, Organisations should clearly separate the roles. Building SharePoint Solution Packages as WSPs requires deployment to be executed on a server joined to the target SharePoint farm. This requires administrative remote desktop access to the server and Organisations should have policies in place to ensure that Developers do not have access to configure deployments themselves. 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.

Community Survey Analysis

Out of the respondents, only 74% stored their source code in Solution Packages for source control.

Real World Example St. Jude Medical maintains a formal change control process, where requests for updates are submitted, then reviewed in UAT, then approved by a release manager (59)

Page 18: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

Recommendations & Guidance

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 System

Development Stand-Alone Environment

Build / Continuous Integration Server

Test Functional &

Integration Testing

Staging Production

Content DB Content DB

Database copied for validating installation (desired but optional)

wsp

wsp wsp

Page 19: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 20: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 21: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 22: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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

Page 23: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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).

Page 24: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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)

Page 25: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 26: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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)

Page 27: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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)

Page 28: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Automatic inclusion of database dependencies e.g. fields, content types, 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)

Requires both environments to be connected for automatic deployment (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).

Page 29: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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

Page 30: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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, ROSS ensures production readiness of sites, and invokes ‘best practice’ for change control within SharePoint.

Pros

Filters – apply granular include/exclude definitions across solutions, content, artefacts, workflows, web parts, permissions, etc., down to file/item level or by Metadata or Content Type

Delegation – administrators can assign pre-configured jobs to non-privileged 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

Real World Example

“With the manual processes of the past, it would take a week or more to move a simple form from staging to production. With ROSS, we can accomplish this same task within minutes.” (36)

Page 31: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Automatic inclusion of database dependencies e.g. fields, content types, master pages (same as Content API)

Granular control down to List Item level on what gets deployed (same as Content API)

Can preserve object GUIDs (same as Content API)

Ability to select options for security, versioning and user roles (same as Content API)

Cons

Open source project unsupported by Microsoft

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)

Requires both environments to be connected for automatic deployment (same as Content API)

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

Community Survey Analysis Out of the respondents, 42% require document approval to deploy Solution Packages into Production or make file server changes to a Production farm. 50% of these respondents did not require approval for UAT/Test deployments.

Page 32: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

Recommendations & Guidance

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.

Page 33: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 34: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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.

Page 35: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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: [email protected] 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.

Page 36: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

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+Imperative+%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.

Page 37: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

19. Microsoft. Developing SharePoint Applications. MSDN. [Online] Aug 2009. http://msdn.microsoft.com/en-us/library/dd203468.aspx.

20. Jackett, Brian. Lessons Learned from Automating a SharePoint Deployment. Brian Jackett's Blog. [Online] Aug 2009. [Cited: ] http://geekswithblogs.net/bjackett/archive/2009/08/11/lessons-learned-from-automating-a-sharepoint-deployment.aspx.

21. Sneddon, Ethan Wilansky and Paul Olszewski and Rick. Automate Web App Deployment with the SharePoint API. MSDN. [Online] May 2008. http://msdn.microsoft.com/en-us/magazine/cc507633.aspx.

22. Blog, Hugo Esperanca's. The SharePoint Maturity Model. Hugo Esperanca's Blog. [Online] July 2008. http://activeobjects.blogspot.com/2008/07/sharepoint-maturity-model-smm_20.html.

23. Capability Maturity Model. Wikipedia. [Online] http://en.wikipedia.org/wiki/Capability_Maturity_Model.

24. Software Engineering Institute. CMMI for Development, Version 1.2. Software Engineering Institute | Carnegie Mellon. [Online] 2006. http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html.

25. O'Brien, Chris. STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared. SharePoint Nuts & Bolts. [Online] Oct 2007. http://www.sharepointnutsandbolts.com/2007/10/stsadm-export-content-deployment.html.

26. —. SharePoint Deployment Options: Features or Content Deployment? SharePoint Nuts & Bolts. [Online] May 2007. http://www.sharepointnutsandbolts.com/2007/05/sharepoint-deployment-optionsfeatures.html.

27. —. Deployment using STSADM export or Content Migration API. SharePoint Nuts & Bolts. [Online] Oct 2007. http://www.sharepointnutsandbolts.com/2007/10/deployment-using-stsadm-export-or.html.

28. Curry, Ben. Bad Practice #1: Not using Solutions for deploying artifacts to the server(s). Beny Curry's Blog. [Online] 08 2009. http://sharepoint.mindsharpblogs.com/Ben/archive/2009/08/08/Bad-Practice-%5Bhash%5D1%5Bcoln%5D-Not-using-Solutions-for-deploying-artifacts-to-the-server(s).aspx.

29. Mastykarz, Waldek. SharePoint 2007 lacks configuration deployment mechanism. Waldek Mastykarz. [Online] Feb 2008. http://blog.mastykarz.nl/sharepoint-2007-lacks-configuration-deployment-mechanism/.

30. Goßner, Stefan. Deep Dive into the SharePoint Content Deployment and Migration API. Stefan Goßner's Blog. [Online] Aug 2007. http://blogs.technet.com/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-1.aspx.

31. Rackley, Mark. SharePoint Solution Deployment Strategies – Dare I say Best Practices? The SharePoint Hillbilly. [Online] Jul 2009. http://sharepointhillbilly.com/archive/2009/06/12/sharepoint-solution-deployment-strategies-ndash-dare-i-say-best-practices.aspx.

32. Rackley, Martin. 10 SharePoint Deployment Standards. Martin Rackley's Blog. [Online] Sep 2009. http://geekswithblogs.net/SoYouKnow/archive/2009/09/10/10-sharepoint-deployment-standards.aspx.

33. Butler, Tyler. Content Deployment. SharePoint Team Blog. [Online] Microsoft, May 2006. http://blogs.msdn.com/sharepoint/archive/2006/05/02/content-deployment.aspx.

34. Johnny Smith. MOSS 2007 Content Deployment Options Comparison. [Online] http://www.sharepointblogs.com/lovedjohnysmith/archive/2008/03/25/moss-2007-content-deployment-options-comparison.aspx.

35. Microsoft. Modifying out-of-the-box SharePoint files. UK SharePoint Team Blog. [Online] Jun 2009. http://blogs.msdn.com/uksharepoint/archive/2009/06/19/modifying-out-of-the-box-sharepoint-files.aspx.

36. Roldan, Yuri. Corporate Manager. 4 August 2009.

Page 38: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

37. Microsoft. Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions. Microsoft. [Online] Jan 2008. http://www.microsoft.com/downloads/details.aspx?FamilyID=65F21935-CBC0-4178-8C08-4C56F721C87D&displaylang=en#filelist.

38. —. Error message when you use SharePoint Central Administration to run a content deployment job in SharePoint Server 2007. Microsoft Help and Support. [Online] May 2007. http://support.microsoft.com/kb/923592.

39. O'Brien, Chris. Content Deployment Wizard. CodePlex. [Online] Sep 2008. http://www.codeplex.com/SPDeploymentWizard.

40. Microsoft. Solution and Authored Artifact Development Models for SharePoint Products and Technologies. MSDN. [Online] April 2009. http://msdn.microsoft.com/en-us/library/dd179854.aspx.

41. —. Team-Based Development in Microsoft Office SharePoint Server 2007. MSDN. [Online] http://msdn.microsoft.com/en-us/library/bb428899.aspx.

42. Alirezaei, Reza. How I Benefit from Native Boot From VHD. Reza Alirezaei's Blog. [Online] Aug 2009. http://blogs.devhorizon.com/reza/?p=989.

43. SharePoint 3rd Party Product Review Checklist Recommendations. SharePointDevWiki.com. [Online] Sep 2009. http://www.sharepointdevwiki.com/display/public/SharePoint+3rd+Party+Product+Review+Checklist+Recommendations.

44. Thake, Jeremy. SharePoint Implementations: the 80/20 rule. Jeremy Thake's Blog. [Online] Aug 2009. http://wss.made4the.net/archive/2009/08/11/sharepoint-implementations-the-8020-rule.aspx.

45. SharePointDevWiki.com. When to Dispose SharePoint objects . SharePointDevWiki.com. [Online] Apr 2009. http://www.sharepointdevwiki.com/display/public/When+to+Dispose+SharePoint+objects.

46. —. Accessing list items using the object model . SharePointDevWiki.com. [Online] Aug 2009. http://www.sharepointdevwiki.com/display/public/Accessing+list+items+using+the+object+model.

47. Wikipedia. Application Lifecycle Management. Wikipedia. [Online] 2009. http://en.wikipedia.org/wiki/Application_lifecycle_management.

48. WikiPedia. Content Management. WikiPedia. [Online] 2009. http://en.wikipedia.org/wiki/Content_management.

49. —. Content Management. WikiPedia. [Online] 2009. http://en.wikipedia.org/wiki/Content_management.

50. Wikipedia. Application Lifecycle Management. Wikipedia. [Online] 2009. http://en.wikipedia.org/wiki/Application_lifecycle_management.

51. SharePointDevWiki. Defining SharePoint Development. SharePointDevWiki.com. [Online] April 2009. http://www.sharepointdevwiki.com/display/public/Defining+SharePoint+Development.

52. Microsoft. Deploying and Upgrading Solutions. MSDN. [Online] 2009. http://msdn.microsoft.com/en-us/library/dd206931.aspx.

53. —. Team-Based Development in Microsoft Office SharePoint Server 2007. MSDN. [Online] April 2007. http://msdn.microsoft.com/en-us/library/bb428899.aspx.

54. CMM - An Introduction. [Online] http://homepages.com.pk/kashman/CMMIntro.htm.

55. Netmsev, Michael. SharePoint Farm configuring and deployment Part 3 – Development Environment. SharePointMagazine.net. [Online] Jun 2009. http://sharepointmagazine.net/technical/administration/best-practices-of-sharepoint-farm-configuring-and-deployment-part-3-development-environment .

Page 39: Share point content and application lifecycle management guidance

SharePoint Content & Application Lifecycle Management Guidance

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

56. Taylor, Rick. Walk the walk that you talk - PART 1 . Rick Taylor's Blog. [Online] Mar 2008. http://blogs.technet.com/ritaylor/archive/2008/03/16/walk-the-walk-that-you-talk-part-1.aspx.

57. Microsoft. SharePoint Products and Technologies customization policy . TechNet. [Online] Jun 2007. http://technet.microsoft.com/en-us/library/cc263010.aspx.

58. Maslowski, Brian. Application Lifecycle Management in SharePoint. SharePoint Saturday New York. [Online] Aug 2009. http://www.sharepointsaturday.org/ny/meetings/65/ApplicationLifecycleManagementinSharePoint.aspx.

59. Chin, Raymond. Systems Analyst. 23 June 2009.


Recommended