Deploy customizations - overview (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
The articles in this chapter describe how to deploy site elements that have been customized by developers or Web designers in a Microsoft SharePoint Foundation 2010 environment.
In this article:
Process overview
Before you begin
About the two kinds of customizable site elements
Deploying developed site elements
Deploying authored site elements
Process overview
Deploying customizations can be quite complex, particularly because there are many deployment methods available in SharePoint Foundation 2010, and the advantages of using one method over another are not always obvious.
You deploy these different types of site elements, or artifacts, by using different methods. You cannot deploy the full range of customizable site elements by using a single deployment method. There are other unique deployment considerations that apply to each type of element because they are likely to originate from different groups of designers, and because they are subject to different upgrade considerations. The different kinds of site elements are described in About the two kinds of customizable site elements, later in this article.
For specific deployment tasks and related considerations, see the following articles:
Before you begin
Before you deploy any custom code to the environment, you should establish a baseline of the environment’s performance so that you can analyze how customizations affect performance. After you have established a performance baseline, test the custom code thoroughly in a test or integration environment and compare the results with the baseline. Make sure that you thoroughly test all customizations before you deploy them to the production environment.
You should also test any code that you acquire from third parties before you deploy it to the production environment, even if you acquire it from a trusted source.
The descriptions and guidance in these articles apply to a SharePoint Foundation environment that has been deployed and configured to meet the requirements in Server farm and environment planning (SharePoint Foundation 2010).
About the two kinds of customizable site elements
Developed site elements are solution artifacts and are typically 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, which are 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 Foundation 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.
Deploying developed site elements
Developed site elements can be generally defined as site elements that are created in a code-development environment and are deployed directly to front-end Web servers and application servers. These site elements are customized typically by developers by using Microsoft Visual Studio 2010 Tools for SharePoint 2010, Microsoft Office SharePoint Designer, or XML editing tools. For more information, see SharePoint Foundation Development Tools (https://go.microsoft.com/fwlink/p/?LinkId=183360).
Note
This article does not discuss the deployment of developed site elements that are deployed as sandboxed solutions. Sandboxed solutions are solutions that can access a subset of the server object model and a subset of feature elements that site collection administrators can deploy. For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).
A best practice is to use solution packages and Windows PowerShell to deploy developed site elements. The SharePoint Foundation 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. Deploying site elements by manually handling code and files can lead to inconsistencies in the upgrade process and can result in servers that are not synchronized with other servers. You can use solution packages to deploy developed site elements from developer environments to integration farms and then to staging, pilot, and production farms.
You can use Windows PowerShell cmdlets to create, import, export and provision solution packages, which leverage the Solution Framework to distribute developed site element customizations. Windows PowerShell cmdlets are useful for deployment of site customizations in most environments because they are included with SharePoint Foundation 2010, and you can use them alone or in conjunction with other methods. You can use Windows PowerShell cmdlets to deploy both artifacts and developed site elements. You can also use cmdlets to activate Features that are deployed in a solution package.
Deploying authored site elements
Authored site elements differ from developed site elements in that they are stored in the content database, although they can depend on resources that exist in the file system of Web servers or — less typically — application servers. In some cases, authored site elements do not function because they require that developed site elements be deployed first.
In environments where customization deployments are entirely automated, the required deployment order can be enforced by the system to eliminate synchronization issues. However, if customization deployment is partially or wholly manual, you must ensure that all required resources are in place on the Web servers and application servers before you deploy any content that relies on those resources.
You deploy authored site elements from authoring environments to staging, pilot, and production farms by using one or more of several different systems. The following table describes these systems and their associated interfaces and usage scenarios.
| Deployment system | Usage scenario |
|---|---|
SharePoint Central Administration Web site |
In environments where source and destination farms are connected by a network, you 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 you 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), you 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). For more information, see Content Migration (https://go.microsoft.com/fwlink/p/?LinkId=183372). |
Windows PowerShell |
You 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 you 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 you can use it alone or with other methods. You can use Windows PowerShell cmdlets to deploy both artifacts and developed site elements. For more information, see SharePoint 2010 Products administration by using Windows PowerShell. |
Custom Web service |
You can create a custom Web service that automates content migration and deployment. You can write custom scripts and Windows applications to execute specific tasks within this process. For more information about programmatic methods for writing a custom Web service, see the following resources in the Microsoft SharePoint 2010 Software Development Kit (SDK):
|
Manual code handling |
In smaller, disconnected environments, or in environments in which authored site elements are not continually customized, you 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. For more information, see Deploy site elements by using Features (SharePoint Foundation 2010). |
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. |
See Also
Concepts
Deploy solution packages (SharePoint Foundation 2010)
Deploy authored site elements (SharePoint Foundation 2010)
Deploy site elements by using Features (SharePoint Foundation 2010)
Deploy templates (SharePoint Foundation 2010)
Other Resources
Resource Center: Installation and Deployment for SharePoint Foundation 2010