Déployer des personnalisations

Article
06/12/2012

Mise à jour : 2008-09-11

In this article:

About the two classes of customizable site elements
Deploying developed site elements
Deploying authored site elements

This article and the resources listed later in this article describe how to deploy customizations of Microsoft Office SharePoint Server 2007 site elements in an enterprise environment.

These articles provide:

A comprehensive list of the processes involved in deploying customized site elements in an enterprise environment.
Procedures for each step of the deployment process.

Before reading this article, see the following resources to learn about the different approaches and environmental considerations:

Deploying customizations can be quite complex, particularly because there are many deployment options available in Office SharePoint Server 2007. There are two distinct classes of customizable site elements: developed site elements and authored site elements. The two classes are differentiated by:

Where the files are stored in a Office SharePoint Server 2007 farm.
Which team in the organization is responsible for administering the site element.
What deployment mechanism the site element requires.

There are often several different methods of deploying customizations for a given environment, and the advantages of using one method over another are not always obvious.

One general best practice for customizations is to keep detailed notes about customizations you make to any files that are in the setup directory. Such customizations might be overwritten during an update or upgrade. If you have detailed notes, you can more easily reapply the customizations after an upgrade. For more information about upgrading customizations, see Vue d’ensemble de la mise à niveau depuis SharePoint Portal Server 2003 vers Office SharePoint Server 2007 et de nouvelles méthodes pour les personnalisations courantes.

Important :
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. You should never deploy any customizations to the production environment without first thoroughly testing them. 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.

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. You should never deploy any customizations to the production environment without first thoroughly testing them.

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.

Scénarios de personnalisation outlines different approaches for deploying customizations to the following two example environments that represent different levels of complexity within the range of environments:

**Author-centric **An agile environment in which flexibility and speed of deployment take precedence over rigorous source control. An author-centric environment uses many of the built-in features of Office SharePoint Server, such as the content deployment system and the Content Migration application programming interface (API).
**Developer-centric **An environment used by enterprises that perform ongoing and complex development by using Office SharePoint Server 2007 as a platform. Agility is sacrificed in favor of a conservative approach to customization review, source control, and testing. Most customizations are conserved in a software configuration management system before being deployed from one farm to another. The developer-centric deployment process typically bypasses some of the built-in features of Office SharePoint Server.

For more information about determining which approach most closely matches the environment, see Déterminez votre approche.

For specific deployment tasks and related considerations, see the following resources:

Remarque :
Guidance in these articles assumes a pre-existing Office SharePoint Server 2007 environment. To ensure that the environment meets the requirements of these articles, see Configurer les environnements serveur.

About the two classes of customizable site elements

Developed site elements, which are typically created by developers, can include:

Web Parts
Workflows
Site and list definitions
Document converters

Conversely, authored site elements, which are typically created by Web designers, can include:

Master pages
Cascading style sheets
Forms
Layout pages

You deploy these different types of site elements 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.

Additionally, authored site elements can be divided into the following two subcategories:

Page elements such as master pages, cascading style sheets, forms, and layout pages.
Content such as text and images.

Content such as text and images would typically not be included in a content deployment package being deployed to a production site, but can be included for testing purposes, such as in a deployment package being deployed from an authoring farm to an integration farm.

For more information, see Examen des éléments de site.

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 Web servers and application servers. These site elements are customized by developers by using Microsoft Office SharePoint Designer, Microsoft Visual Studio 2005 extensions for Windows SharePoint Services 3.0, or XML editing tools. For more information, see Révision des outils et processus.

You can deploy developed site elements from developer environments to integration farms and then to staging, pilot, and production farms by using one or more different systems. The following table describes these systems and their associated interfaces and usage scenarios.

Deployment system	Interface	Usage scenario
Solution Framework	Stsadm command-line tool	You can use the Stsadm command-line tool to create, import, export and provision solution packages, which leverage the Office SharePoint Server 2007 Solution Framework to distribute developed site element customizations. The Stsadm tool is useful for deployment of site customizations in most environments because it is included with both Windows SharePoint Services 3.0 and Office SharePoint Server 2007, and you can use it alone or in conjunction with other methods. You can use the Stsadm command-line tool to deploy both artifacts and developed site elements. For more information, see Outil de ligne de commande Stsadm (Office SharePoint Server).
	Solution Generator	This method is most useful when you are using Visual Studio 2005 to create and deploy site definitions. The SharePoint Solution Generator is a stand-alone application that generates a Site Definition project from an existing SharePoint site. The application enables developers to use the browser and Microsoft Office SharePoint Designer to customize the content of their sites before creating code by using Visual Studio. For more information and to download the tool, see Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions (https://go.microsoft.com/fwlink/?LinkId=107267&clcid=0x409).
	Custom scripts and applications	You can create timer jobs in SharePoint Products and Technologies that can automate the creation and deployment of solution packages. You can write custom scripts and Windows applications to execute specific tasks within this process.
Manual code handling	Not applicable	In smaller environments, or environments in which developed site elements are not customized on an ongoing basis, you can manually deploy site elements and related resources. For more information, see the Windows SharePoint Services 3.0 Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=86923&clcid=0x409).
Features	Not applicable	Windows SharePoint Services 3.0 introduces an inherently portable and modular functionality known as a Feature, which simplifies modification of sites through site definitions. A Feature is a package of Windows SharePoint Services 3.0 elements that can be activated for a specific scope and that can help users accomplish a particular task. For more information, see Working with Features (https://go.microsoft.com/fwlink/?LinkID=105337&clcid=0x409).
Site templates	Not applicable	In Windows SharePoint Services 3.0, a site definition consists of a set of XML files that can be applied to provision new sites. The files are located on Web servers. Additionally, you can also apply a site template (.stp file) to provision new sites. A site template, created through the user interface or through implementation of the object model, is a package that contains a set of differences and changes from a base site definition. The site template package is stored as a CAB file that can be downloaded or uploaded to site collections by users with the appropriate permissions.

For more information, see Déploiement des personnalisations d’éléments de sites développés.

Deploying authored site elements

Authored site elements differ from developed site elements in that they are stored in the content database, although they depend on resources that exist in the file system of Web servers or application servers. In some cases, authored site elements require the prior delivery of developed site elements to function.

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 executed on demand, you must ensure that all required resources are in place on the Web servers and application servers before content that relies on those resources is deployed.

Site elements in this class are usually customized by authors by using the SharePoint Products and Technologies user interface. However, authoring tools can include Office SharePoint Designer 2007 or Visual Studio 2005 extensions for Windows SharePoint Services 3.0. For more information, see Révision des outils et processus.

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	Interface	Usage scenario
SharePoint Central Administration Web site	Content deployment	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	Content Migration API	Depending on the method you use (programming against the deployment namespace APIs, using Simple Object Access Protocol (SOAP) calls to a Web service, or moving an entire site by using the Stsadm command-line tool), 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/?LinkID=103094&clcid=0x409).
	Command line	You can use the Stsadm command-line tool to perform import and export operations against the complete site, preserving time stamps, security information, and user information. The Stsadm tool is most useful when you want to move basic content from a whole Web site. The Stsadm tool is useful for deployment of site customizations in most environments because it is included with both Windows SharePoint Services 3.0 and Office SharePoint Server 2007, and you can use it alone or with other methods. You can use the Stsadm command-line tool to deploy both artifacts and developed site elements. For more information, see Outil de ligne de commande Stsadm (Office SharePoint Server).
	Custom Web service	You can create a custom Web service that automates the content migration and deployment process. You can write custom scripts and Windows applications to execute specific tasks within this process. For more information about programmatic methods associated with writing a custom Web service, see the following resources in the Windows SharePoint Services 3.0 Software Development Kit (SDK): Sites Methods (https://go.microsoft.com/fwlink/?LinkId=107268&clcid=0x409) ExportWeb (https://go.microsoft.com/fwlink/?LinkId=107269&clcid=0x409) ImportWeb (https://go.microsoft.com/fwlink/?LinkId=107270&clcid=0x409)
Manual code handling	Not applicable	In smaller, disconnected environments, or in environments in which authored site elements are not customized continually, 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.
Features	Not applicable	Windows SharePoint Services 3.0 introduces a portable and modular functionality known as a Feature, which simplifies modification of sites through site definitions. A Feature is a package of Windows SharePoint Services 3.0 elements that can be activated for a specific scope and that can help users perform a particular task. For more information about the kinds of elements that can be deployed in a Feature, see Element types (https://go.microsoft.com/fwlink/?LinkId=107271&clcid=0x409) in the Windows SharePoint Services 3.0 SDK.
Site templates	Not applicable	In Windows SharePoint Services 3.0, a site definition consists of a set of XML files that can be applied to provision new sites. The files are located on Web servers. Additionally, you can also apply a site template (.stp file) to provision new sites. A site template, created through the user interface or through implementation of the object model, is a package that contains a set of differences and changes from a base site definition. The site template package is stored as a CAB file that can be downloaded or uploaded to site collections by users who have the appropriate permissions.