SharePoint 2010 Release Management
Deployment - OOB CHANGES
What?
Out of the Box changes in SharePoint 2010 are the changes which can be easily done by Power users under the supervision of the set governance rules. Once we have finalized the Information Architecture document, we can decide how much control we can give to the end users to perform Out of the Box changes. SharePoint categorize the user under following broad categories:
- Visitors: Can only view the site
- Members : Can edit and view the site
- Owners : Can edit, design and view the site
- Administrator : Configuration change done at the end of the server farm. For instance – Search configuration, mysites, etc.
How to deploy?
OOB changes can be directly done to the test environment and then deployed to live using a configuration guide explaining the changes being done. This process can be automated using Powershell if we deploy the whole site collection from test to live. However, if we do not have any tool to check for any customizations, it is better to do all the OOB changes manually on live by preparing a configuration guide for every release.
Deployment – Custom solutions
What?
SharePoint Server 2010’s Feature Framework helps develop Features, and allows administrators to activate or deactivate these features based on their requirements. Typically, we include related or dependent components in a single Feature so that they can be activated or deactivated as a unit. For example, we can include a list definition, a list instance, a Web Part, and a workflow in a Feature where the list instance is based on the list definition, the workflow performs some action on the list, and the Web Part provides a custom user interface for the list data.
In addition to implementing the deployment process, Visual Studio 2010 can be used to debug our deployed solutions in our local development environment directly from the Visual Studio IDE.
We can use Windows PowerShell commands to install our projects anywhere other than our local SharePoint server. Administrators typically deploy solutions by using Windows PowerShell commands. We can use Visual Studio to simply package our solution into a WSP file, rather than both packaging and deploying it.
Before deploying any custom code to the environment, establish a baseline of the environment’s performance so that one can analyze how customizations affect performance. After establishing a performance baseline, test the custom code thoroughly in a test or integration environment and compare the results with the baseline. Make sure that all the customizations are thoroughly tested before being deployed to production environment.
There are typically two kinds of customizable site elements in SharePoint 2010:
Developed Site Elements: Solutions artifacts created by developers. A solution can include assemblies, which are SharePoint components that are written in Microsoft .NET Framework–based languages and compiled before being deployed. Developed site elements, except timer jobs assemblies and site definitions, are typically grouped into Features and deployed as part of a solution package. Developed site elements include:
- Web Parts
- Workflows
- Site and list definitions
- Document converters
- Event receivers
- Timer jobs
- Assemblies
Authored site elements: Typically created by Web designers, are not explicitly compiled and reside in a content database. Authored site elements include:
- Master pages
- Cascading style sheets
- Forms
- Layout pages
- These two kinds of customizable site elements are differentiated by:
- Where the files are stored in a SharePoint Server 2010 farm.
- Which team in the organization is responsible for administering the site element.
- What deployment mechanism the site element requires.
Some elements can be either solution artifacts or authored artifacts. For example, a content type can be defined in an XML file as a developed solution artifact, or created through a browser as an authored artifact. Site elements that can be solution artifacts or authored artifacts include site columns and list instances. Also, solution artifacts can be used to provision files into Web sites and set to be cached in memory on the front-end Web server.
How to deploy custom / authored site elements?
A best practice is to use solution packages and Windows PowerShell to deploy developed custom site elements. The SharePoint Server Solution Framework simplifies and standardizes the process of deploying new and upgrade site elements across the farm and synchronizing a front-end Web server so that its state is consistent with the state of other servers in the farm. For example, solution packages simplify the process of rebuilding a farm.
Windows PowerShell cmdlets can be used to create, import, export and provision solution packages, which leverage the Solution Framework to distribute developed site element customizations. A sample powershell script in the appendix is an example of how to add and deploy solution to the SharePoint farm.
Microsoft recommends the following different deployment scenarios for authored site elements.
Deployment system |
Usage scenario |
|---|---|
SharePoint Central Administration Web site |
In environments where source and destination farms are connected by a network, we can use the content deployment features in Central Administration to create a content deployment package on the source farm and export the package to another farm. This method is easy to configure and use, and can be used to automate deployment of authored site elements with very little setup time and maintenance. |
Content Migration object model |
Depending on the method we use (programming by using the deployment namespace APIs, using Simple Object Access Protocol (SOAP) calls to a Web service, or moving a whole site by using Windows PowerShell cmdlets), we can control what content is migrated and how. Using the API to import and export content is the only supported method that retains globally unique identifiers (GUIDs). |
Windows PowerShell |
We can use Windows PowerShell cmdlets to perform import and export operations against the whole site, preserving time stamps, security information, and user information. Windows PowerShell cmdlets are most useful when we want to move basic content from a whole Web site. Windows PowerShell is useful for deployment of site customizations in most environments because it is included with SharePoint 2010 Products, and we can use it alone or with other methods. We can use Windows PowerShell cmdlets to deploy both artifacts and developed site elements. |
Custom Web service |
We can create a custom Web service that automates content migration and deployment. We can write custom scripts and Windows applications to execute specific tasks within this process. |
Manual code handling |
In smaller, disconnected environments, or in environments in which authored site elements are not continually customized, we can manually deploy site elements and related resources. In smaller connected environments, consider using the content deployment features in Central Administration to deploy authored site element customizations. |
Solution packages and Features |
Elements such as page layouts, master pages, forms, and style sheets, can be grouped and deployed in Features as part of a solution package. Features deployed from a solution package can be activated on the scopes where authored elements need to be provisioned. |
Custom templates |
A user can save an existing site, with or without its specific content, as a custom template. This provides a means for reusing customized sites. A custom site template is stored as a .wsp file. Site templates are saved in the Solution Gallery of the top-level site in a site collection, where they become available for subsite creation on all Web sites in the site collection. Site templates can be downloaded and moved to other site collection galleries. |
What?
Structured Content: Content which is used for document management and collaboration in SharePoint. For instance, every department has a typical content which is required for their respective employees to collaborate. This content is not published quite frequently and is rated as a structured content in SharePoint.
Unstructured Content: Content which is used for publishing daily updates and news articles. For instance, the home page for different publishing sites incorporates unstructured content which is changed on day to day basis.
How to deploy structured / unstructured content?
Content can be deployed from test to live in one of the following ways:
- Migrate the complete site collection from one farm to the other using powershell
- Manually do all the changes straight to live
- Create a content deployment job which automatically migrates the content from test to live overnight
- Develop the custom site element in Development. Compile it in Release Mode
- Use these solution files to deploy for customised elements, that is, utilize WSP files for all SharePoint solutions. Provide the following to SharePoint Administrator for deployment:
- WSP file
- Powershell Script
- Administrator will run the powershell script in one of the SharePoint front end servers of the Farm
- All the Visual Studio 2010 files of the solution (for every release) to be maintained in version management system along with Powershell script. Create a test environment that mimics Production - There is no out of the box support for synchronising content between Live and Test environments. One viable way is to backup the Live content database(s) and restore them on Test environment periodically. Also any customisations, solutions and features must be redeployed as part of each synching cycle. The alternative way is to use tools to directly migrate from test to live and keep both the environment in sync.