Partager via

Déployer des personnalisations - Vue d’ensemble (SharePoint Foundation 2010)

  • Article

 

S’applique à : SharePoint Foundation 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 les développeurs ou les concepteurs Web dans un environnement Microsoft SharePoint Foundation 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 être relativement complexe, en raison notamment des nombreuses méthodes de déploiement disponibles dans SharePoint Foundation 2010 ; par ailleurs, les avantages liés à l’utilisation d’une méthode plutôt qu’une autre ne sont pas toujours évidents.

Vous déployez ces différents types d’éléments de site, ou artefacts, à l’aide de 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 en matière de déploiement s’appliquent à chaque type d’élément, car ces derniers proviennent généralement de différents groupes de concepteurs et 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 plus d’informations sur les tâches de déploiement spécifiques et les considérations qui s’y rapportent, voir 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, testez soigneusement le code personnalisé dans le cadre d’un environnement de test ou d’intégration, puis 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 conseils fournis dans ces articles s’appliquent à un environnement SharePoint Foundation déployé et configuré pour répondre aux exigences décrites dans Planification de batterie de serveurs et de l’environnement (SharePoint Foundation 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 les développeurs. Une solution peut inclure des assemblys, qui sont des composants SharePoint écrits dans des langages basés sur Microsoft .NET Framework et compilés avant d’être déployés. En règle générale, les éléments de site développés, à l’exception des assemblys de travaux du minuteur et des définitions de site, sont regroupés en fonctionnalités et déployés dans le cadre d’un package de solution. Les éléments de site développés rassemblent ce qui suit :

  • 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 créés par les 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 rassemblent ce qui suit :

  • Pages maîtres

  • Feuilles de style en cascade

  • Formulaires

  • Pages de disposition

Ces deux types d’éléments de site personnalisables sont différenciés via les critères suivants :

  • emplacement où les fichiers sont stockés dans une batterie de serveurs SharePoint Foundation 2010 ;

  • équipe de l’organisation chargée de l’administration de l’élément de site ;

  • 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 sous forme d’artefact de solution développé, ou être créé via un navigateur en tant qu’artefact créé. Les éléments de site susceptibles d’être des artefacts de solution ou des artefacts créés rassemblent les colonnes de site et les instances de listes. En outre, les artefacts de solution peuvent être utilisés pour mettre en service des fichiers dans des sites Web et être mis en cache en mémoire 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 créés dans un environnement de développement de code et déployés directement sur des serveurs Web et des serveurs d’applications frontaux. En règle générale, ces éléments de site sont personnalisés par des développeurs à l’aide de Microsoft Visual Studio 2010 Tools pour SharePoint 2010, Microsoft Office SharePoint Designer ou les 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 traite pas du déploiement des éléments de site développés qui sont déployés en tant que solutions en mode bac à sable. Ces dernières sont des solutions qui peuvent accéder à un sous-ensemble du modèle objet serveur et à un sous-ensemble des éléments de fonctionnalités que les administrateurs de collection de sites peuvent déployer. Pour plus d’informations, voir Vue d’ensemble des solutions en bac à sable (SharePoint Foundation 2010).

Il est recommandé d’utiliser des packages de solution et Windows PowerShell pour déployer les éléments de site développés. La structure de solution SharePoint Foundation simplifie et normalise le processus de déploiement des éléments de site nouveaux ou mis à niveau dans la batterie de serveurs, ainsi que la synchronisation d’un serveur Web frontal de sorte que son état soit cohérent par rapport à l’état des autres serveurs de la batterie. Par exemple, les packages de solution simplifient le processus de reconstruction d’une batterie de serveurs. Le déploiement d’éléments de site par la gestion manuelle du code et des fichiers peut mener à des incohérences dans le processus de mise à niveau et entraîner une désynchronisation des serveurs par rapport à d’autres serveurs. Les packages de solution vous permettent de déployer des éléments de site développés à partir des environnements de développement vers des batteries de serveurs d’intégration, puis vers des batteries de serveurs intermédiaires, 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 parti 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 des personnalisations de site dans la plupart des environnements, car elles sont incluses dans SharePoint Server 2010 et SharePoint Foundation 2010 ; par ailleurs, vous pouvez les utiliser de manière autonome ou conjointement avec d’autres méthodes. Les applets de commande Windows PowerShell vous permettent de déployer à la fois des artefacts et des éléments de site développés. Vous pouvez également utiliser les applets de commande pour activer des fonctionnalités déployées dans un package de solution.

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

Les éléments de site créés se distinguent 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 présentes dans le système de fichiers des serveurs Web ou (moins fréquemment) des serveurs d’applications. Dans certains cas, les éléments de site créés ne fonctionnent pas, car ils nécessitent que les éléments de site développés soient déployés en premier.

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 du contenu basé 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 de 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 vers une autre batterie de serveurs.

Cette méthode est facile à configurer et à utiliser, et peut servir à 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 à l’aide d’API d’espace de noms de déploiement, à l’aide d’appels SOAP (Simple Object Access Protocol) à un service Web ou déplacement d’un site entier à l’aide d’applets de commande Windows PowerShell), vous pouvez contrôler le contenu migré et son mode de migration. 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 les 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 essentiellement utiles lorsque vous souhaitez déplacer le contenu de base d’un site Web tout entier.

Windows PowerShell est utile pour le déploiement de personnalisations de site dans la plupart des environnements, car il est inclus dans Produits SharePoint 2010 ; par ailleurs, vous pouvez l’utiliser de manière autonome ou conjointement avec d’autres méthodes. Les applets de commande Windows PowerShell vous permettent de 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 relatives à l’écriture d’un service Web personnalisé, voir 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, 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 fonctionnalités

Les éléments tels que les mises en page, pages maîtres, formulaires et feuilles de style peuvent être regroupés et déployés en tant que fonctionnalités dans le cadre d’un package de solution. Les fonctionnalités déployées à partir d’un package de solution peuvent être activées pour 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 Foundation 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é en tant que 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 sont disponibles pour la création de sous-sites de l’ensemble des 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 solution (SharePoint Foundation 2010)
Déployer des éléments de site créés (SharePoint Foundation 2010)
Déployer des éléments de sites à l’aide de composants fonctionnels (SharePoint Foundation 2010)
Déployer des modèles (SharePoint Foundation 2010)