Déployer des personnalisations : vue d’ensemble (SharePoint Server 2010)

  • Article

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Les articles de ce chapitre expliquent comment déployer des éléments de site qui ont été personnalisés par des développeurs ou des concepteurs Web dans un environnement Microsoft SharePoint Server 2010.

Dans cet article :

  • Vue d’ensemble du processus

  • Avant de commencer

  • À propos des deux types d'éléments de site personnalisables

  • Déploiement d'éléments de site développés

  • Déploiement d'éléments de site créés

Vue d’ensemble du processus

Le déploiement de personnalisations peut s’avérer plutôt complexe, en particulier parce que de nombreuses méthodes de déploiement sont disponibles dans SharePoint Server 2010, et les avantages de l’utilisation d’une méthode par rapport à une autre ne sont pas toujours évidents.

Vous déployez ces différents types d’éléments de site, ou artefacts, avec différentes méthodes. Vous ne pouvez pas déployer la gamme complète des éléments de site personnalisables avec une seule méthode de déploiement. D’autres considérations uniques s’appliquent à chaque type d’élément, parce qu’ils proviennent généralement de différents groupes de concepteurs et qu’ils font appel à des concepts de mise à niveau différents. Les différents types d’éléments de site sont décrits dans À propos des deux types d'éléments de site personnalisables, plus loin dans cet article.

Pour des tâches de déploiement spécifiques et les considérations qui s’y rapportent, consultez les articles suivants :

Avant de commencer

Avant de déployer du code personnalisé dans l’environnement, vous devez définir une ligne de base pour les performances de l’environnement afin de pouvoir analyser la manière dont les personnalisations affectent les performances. Une fois que vous avez défini une ligne de base pour les performances, essayez soigneusement le code personnalisé dans le cadre d’un environnement de test ou d’intégration et comparez les résultats à la ligne de base. Veillez à tester soigneusement toutes les personnalisations avant de les déployer dans l’environnement de production.

Vous devez également tester le code provenant de tiers avant de le déployer dans l'environnement de production, même s'il provient d'une source approuvée.

Les descriptions et l’aide indiquées dans ces articles s’appliquent à un environnement SharePoint Server qui a été déployé et configuré de manière à satisfaire aux conditions stipulées dans Planifier les batteries et les environnements de serveurs (SharePoint Server 2010).

À propos des deux types d’éléments de site personnalisables

Les éléments de site développés sont des artefacts de solution et sont généralement créés par des développeurs. Une solution peut comprendre des assemblys, qui sont des composants SharePoint écrits dans des langages Microsoft .NET Framework et compilés avant d’être déployés. Les éléments de site développés, à l’exception des définitions de site et des assemblys des travaux du minuteur, sont généralement regroupés en composants fonctionnels et déployés dans le cadre d’un package de solution. Les éléments de site développés sont les suivants :

  • Composants WebPart

  • Flux de travail

  • Définitions de site et de liste

  • Convertisseurs de documents

  • Récepteurs d’événements

  • Travaux du minuteur

  • Assemblys

Les éléments de site créés, qui sont généralement réalisés par des concepteurs Web, ne sont pas explicitement compilés et résident dans une base de données de contenu. Les éléments de site créés sont les suivants :

  • Pages maîtres

  • Feuilles de style en cascade

  • Formulaires

  • Pages de disposition

Ces deux types d’éléments de site personnalisables se différencient par :

  • l’endroit où les fichiers sont stockés dans une batterie de serveurs SharePoint Server 2010 ;

  • l'équipe de l'organisation qui est chargée de l'administration de l'élément de site ;

  • le mécanisme de déploiement dont a besoin l'élément de site.

Certains éléments peuvent être des artefacts de solution ou des artefacts créés. Par exemple, un type de contenu peut être défini dans un fichier XML en tant qu’artefact de solution développé ou être créé par le biais d’un navigateur en tant qu’artefact créé. Les éléments de site qui peuvent être des artefacts de solution ou des artefacts créés comprennent les colonnes de site et les instances de listes. En outre, les artefacts de solution permettent de déployer les fichiers dans les sites Web et peuvent être définis de manière à résider en mémoire cache sur le serveur Web frontal.

Déploiement d'éléments de site développés

Les éléments de site développés peuvent généralement être définis comme des éléments de site qui sont créés dans un environnement de développement de code et déployés directement sur des serveurs Web frontaux et des serveurs d’applications. Ces éléments de site sont généralement personnalisés par des développeurs avec Microsoft Visual Studio 2010 Tools for SharePoint 2010, Microsoft Office SharePoint Designer ou des outils d’édition XML. Pour plus d’informations, voir Outils de développement SharePoint Foundation (https://go.microsoft.com/fwlink/?linkid=183360&clcid=0x40C).

Notes

Cet article ne présente pas le déploiement d’éléments de site développés déployés en tant que solutions en bac à sable. Les solutions en bac à sable sont des solutions qui peuvent accéder à un sous-ensemble du modèle d’objet serveur et à un sous-ensemble des éléments de fonctionnalité que les administrateurs de collections de sites peuvent déployer. Pour plus d’informations, voir Vue d’ensemble de solutions en bac à sable (SharePoint Server 2010).

Une meilleure pratique consiste à utiliser des packages de solution et Windows PowerShell pour déployer les éléments de site développés. La structure de solution SharePoint Server simplifie et standardise le processus de déploiement des éléments de site nouveau et de mise à niveau dans la batterie de serveurs, ainsi que le processus de synchronisation d’un serveur Web frontal afin que son état soit cohérent avec celui des autres serveurs de la batterie. Par exemple, les packages de solution simplifient le processus de régénération d’une batterie de serveurs. Le déploiement d’éléments de site par le biais d’une gestion manuelle du code et des fichiers peut se traduire par des incohérences dans le processus de mise à niveau et par un défaut de synchronisation entre les serveurs. Vous pouvez utiliser des packages de solution pour déployer des éléments de site développés depuis des environnements de développement vers des batteries de serveurs d’intégration, puis vers des batteries de serveurs de test, pilotes et de production.

Vous pouvez utiliser des applets de commande Windows PowerShell pour créer, importer, exporter et mettre en service des packages de solution, qui tirent profit de la structure de solution pour distribuer les personnalisations d’éléments de site développés. Les applets de commande Windows PowerShell sont utiles pour le déploiement de personnalisations de site dans la plupart des environnements, parce qu’elles sont incluses aussi bien avec SharePoint Server 2010 que SharePoint Foundation 2010 et que vous pouvez les utiliser seules ou avec d’autres méthodes. Vous pouvez utiliser des applets de commande Windows PowerShell pour déployer à la fois des artefacts et des éléments de site développés. Vous pouvez également utiliser des applets de commande pour activer les composants fonctionnels déployés dans un package de solution.

Déploiement d'éléments de site créés

Les éléments de site créés sont différents des éléments de site développés, car ils sont stockés dans la base de données de contenu, bien qu’ils puissent dépendre de ressources figurant dans le système de fichiers des serveurs Web ou, plus rarement, des serveurs d’applications. Parfois, les éléments de site créés ne fonctionnent pas, car il est nécessaire que les éléments de site développés soient préalablement déployés.

Dans des environnements où les déploiements de personnalisation sont entièrement automatisés, l’ordre de déploiement requis peut être appliqué par le système afin d’éliminer les problèmes de synchronisation. Toutefois, si le déploiement de personnalisation est partiellement ou totalement manuel, vous devez vous assurer que toutes les ressources nécessaires sont en place sur les serveurs Web et les serveurs d’applications avant de déployer le contenu qui repose sur ces ressources.

Vous déployez les éléments de site créés à partir d'environnements de création vers des batteries de serveurs intermédiaires, pilotes et de production en utilisant un ou plusieurs des différents systèmes possibles. Le tableau suivant décrit ces systèmes et leurs interfaces et les scénarios d'utilisation.

Système de déploiement Scénario d’utilisation

Site Web d'administration centrale SharePoint

Dans des environnements où les batteries de serveurs source et de destination sont connectées par un réseau, vous pouvez utiliser les fonctionnalités de déploiement de contenu de l'administration centrale pour créer un package de déploiement de contenu sur la batterie de serveurs source et l'exporter sur une autre batterie de serveurs.

Cette méthode est facile à configurer et à utiliser et elle peut servir pour automatiser le déploiement des éléments de site créés, avec peu de temps de configuration et de maintenance.

Modèle objet de migration de contenu

En fonction de la méthode que vous utilisez (programmation en utilisant des API d’espace de noms de déploiement, en utilisant des appels SOAP (Simple Object Access Protocol) à un service Web ou en déplaçant un site entier à l’aide d’applets de commande Windows PowerShell), vous pouvez contrôler quel contenu est migré et comment. L’utilisation de l’API pour importer et exporter le contenu est la seule méthode prise en charge qui préserve les identificateurs globaux uniques (GUID).

Pour plus d’informations, voir Migration de contenu (https://go.microsoft.com/fwlink/?linkid=183372&clcid=0x40C).

Windows PowerShell

Vous pouvez utiliser des applets de commande Windows PowerShell pour effectuer des opérations d’importation et d’exportation sur un site entier, en préservant les horodatages, les informations de sécurité et les informations des utilisateurs. Les applets de commande Windows PowerShell sont utiles surtout lorsque vous souhaitez déplacer du contenu de base à partir d’un Web entier.

Windows PowerShell est utile pour le déploiement de personnalisations de site dans la plupart des environnements, parce qu’il est inclus avec les Produits SharePoint 2010 et que vous pouvez l’utiliser seul ou avec d’autres méthodes. Vous pouvez utiliser des applets de commande Windows PowerShell pour déployer à la fois des artefacts et des éléments de site développés.

Pour plus d’informations, voir Administration des produits SharePoint 2010 à l’aide de Windows PowerShell.

Service Web personnalisé 

Vous pouvez créer un service Web personnalisé qui automatise la migration de contenu et le déploiement. Vous pouvez écrire des applications Windows et des scripts personnalisés pour exécuter des tâches spécifiques dans le cadre de ce processus.

Pour plus d’informations sur les méthodes de programmation pour l’écriture d’un service Web personnalisé, consultez les ressources suivantes dans le kit de développement logiciel (SDK) de Microsoft SharePoint 2010 :

Gestion manuelle du code

Dans des environnements déconnectés plus petits, ou dans des environnements dans lesquels les éléments de site créés ne sont pas personnalisés en continu, vous pouvez déployer manuellement des éléments de site et les ressources apparentées. Dans des environnements connectés plus petits, pensez à utiliser les fonctionnalités de déploiement de contenu de l’Administration centrale pour déployer les personnalisations d’éléments de site créés.

Packages de solution et composants fonctionnels

Les éléments tels que les mises en page, les pages maîtres, les formulaires et les feuilles de styles peuvent être regroupés et déployés sous la forme de composants fonctionnels dans le cadre d’un package de solution. Les composants fonctionnels déployés à partir d’un package de solution peuvent être activés sur les étendues où les éléments créés doivent être mis en service.

Pour plus d’informations, voir Déployer des éléments de sites à l’aide de composants fonctionnels (SharePoint Server 2010).

Modèles personnalisés

Un utilisateur peut enregistrer un site existant, avec ou sans son contenu spécifique, en tant que modèle personnalisé. Cela permet de réutiliser les sites personnalisés. Un modèle de site personnalisé est stocké sous la forme d’un fichier .wsp. Les modèles de sites sont enregistrés dans la galerie de solutions du site de niveau supérieur d’une collection de sites, où ils deviennent disponibles pour la création de sous-sites sur tous sites Web de la collection de sites. Les modèles de sites peuvent être téléchargés et déplacés vers d’autres galeries de collections de sites.

See Also

Concepts

Déployer des packages de solutions (SharePoint Server 2010)
Déployer des éléments de sites créés (SharePoint Server 2010)
Déployer des modèles (SharePoint Server 2010)
Déployer des modèles (SharePoint Server 2010)