SharePoint 2010 : Solution emballage

Après que vous avez développé vos solutions SharePoint, comment empaqueter et déployer est la dernière partie du processus.

Steve Wright et Corey Erkes

Adapté de « Gouvernance SharePoint Pro 2010 » (Apress, 2012)

Lorsque vous développez des solutions à utiliser au sein de SharePoint, vous avez encore des options quant à la façon d'empaqueter et de déployer ces solutions. SharePoint utilise le cadre de la solution pour installer des améliorations personnalisées dans un environnement de SharePoint.

Le cadre de la solution vous permet de déployer, d'activer et de mettre à jour les composants personnalisés de façon contrôlée. Cette structure vise à stabiliser la batterie de serveurs SharePoint. Vos packages de solution peuvent contenir des fichiers de ressources pour une approche cohérente de la localisation de vos composants personnalisés. Le cadre de la solution remplace les autres technologies d'installation utilisées dans les environnements Windows tels que les fichiers Microsoft Installer (MSI) et ClickOnce.

Packages de solution fournissent également un moyen de regrouper tous les composants associés à une mise en valeur personnalisée dans un fichier avec une extension WSP. Vous pouvez ensuite déployer ces fichiers à la ferme pour tous les composants installés simultanément sur tous les serveurs de la batterie de serveurs. Cela supprime la nécessité de maintenir les fichiers de page Web, les modèles et les fichiers exécutables séparément sur chaque serveur.

Le SharePoint 2010 solution framework inclut également de nouvelles fonctionnalités qui aident à vous mettre à jour les packages de solution en place sans interférer avec l'exploitation agricole. Vous pouvez faire cela de versioning que chacun déployé fonctionnalité et fournit des actions personnalisées de mise à niveau d'une version d'une fonctionnalité à l'autre.

Packages de solutions

Un fichier de package de solution est un seul fichier avec une extension de nom de fichier WSP. Toutefois, ce qui semble être un fichier peut en fait être plusieurs fichiers archivés en un seul. Le format de fichier WSP n'est en fait rien d'autre qu'un fichier (CAB) standard Windows. Pour prouver ceci, prenez n'importe quel fichier de solution et remplacez l'extension de WSP CAB. Maintenant, ouvrez le fichier et vous verrez la structure de fichiers.

Il y a un fichier de manifeste de package dans le répertoire racine et un ou plusieurs sous-répertoires contenant les autres composants. Plusieurs de ces composants sont des fichiers XML avec les informations de configuration pour les listes, sites, types de contenu et ainsi de suite.

Les fichiers de plus commun que vous trouverez dans un package de solution sont :

  • **Manifest.xml :**Il y a un fichier manifeste dans un paquet. Il contient une description de tous les éléments de l'emballage, soit directement, soit par le biais de références aux autres fichiers.
  • **Feature.xml :**Ces fichiers décrivent la configuration et les composants associés à une fonction. Vous pouvez activer ces activé ou désactivé dans l'environnement SharePoint.
  • **Elements.xml :**Ces fichiers contiennent des listes des différents composants et leurs informations de configuration. Les composants sont des éléments tels que les instances de listes, fichiers de contenu, les colonnes de site, types de contenu et les récepteurs d'événements.
  • **Schema.xml :**Ces fichiers contiennent les spécifications des métadonnées pour un objet tel qu'un modèle de liste.

Il y a beaucoup d'autres types de fichiers qui apparaissent dans un package de solution, mais ce sont les plus importants. Ils contrôlent la configuration de la fonctionnalité et composant. Avant de les utiliser, vous devez comprendre un peu l'environnement auquel ils va être déployés.

Comprendre les environnements de déploiement

Lorsque vous déployez un package de solution sur une batterie de serveurs SharePoint, il déploie dans l'un des deux environnements d'exécution. La première est la batterie de serveurs se. Cela donne les composants de la solution de la capacité d'accéder aux ressources dans l'ensemble de la ferme et au-delà, dans les limites des autorisations d'accès sur ces éléments.

Le deuxième environnement — la sandbox — est beaucoup plus limité. Lors de l'exécution d'un package de solution en bac à sable, sa capacité d'influer sur l'exploitation agricole dans son ensemble est limitée. Comprendre la différence entre les solutions de batterie et les solutions en sandbox est essentielle au déploiement de la planification des améliorations personnalisées.

La première chose à considérer est où la solution sera déployée. Solutions de batterie sont globale pour la batterie de serveurs. Solutions en bac à sable sont locales à une collection de sites spécifique. Si plusieurs collections de sites ont besoin d'utiliser votre solution en bac à sable, vous devrez déployer pour chacun d'eux séparément.

La principale différence entre la ferme et des solutions en bac à sable est la sécurité. Solutions de batterie généralement exécutent avec une confiance totale. À l'aide de .NET (CAS, Code Access Security), vous pouvez créer des composants de solution de batterie de serveurs qui s'exécutent avec une confiance totale inférieure à. C'est une bonne idée du point de vue de la sécurité, car il permet le code exécuté avec l'ensemble minimal de privilèges nécessaires. Vous devez réserver le déploiement de la batterie pour code éprouvé et hautement approuvé.

Solutions en sandbox exécutent dans un environnement de sécurité très différentes. Leur accès aux ressources est limitée à la collection de sites dans lesquels ils sont déployés. Il y a aussi des restrictions de ressources et de quotas, vous pouvez appliquer pour éviter de compromettre les performances du système, les composants de solution rogue. Vous pouvez facilement désactiver la mauvaise conduite des solutions en sandbox et empêchez leur exécution entièrement, si nécessaire.

Gérer vos solutions de batterie

Déploiement d'un package de solution à une batterie de serveurs SharePoint est constituée de deux opérations de base : Ajouter et déployer. L'opération d'ajout transfère le fichier de solution dans la base de données de configuration SharePoint, où il peut être consulté par chaque serveur de la batterie. Déployer installe les fichiers dans les différents répertoires de système de fichiers sur chaque serveur de la batterie.

Seuls les administrateurs de batterie peuvent ajouter des solutions au magasin de solutions de batterie de serveurs. Il n'y a aucune page dans l'Administration centrale qui vous permet de télécharger un paquet. Il faut le faire avec un outil de ligne de commande. Vous pouvez également ajouter des solutions à l'aide de l'API SharePoint.

Pour utiliser l'outil STSADM pour ajouter le package, utilisez une commande semblable à la suivante :

stsadm-o addsolution - filename MySolution.wsp

Pour effectuer la même opération à l'aide de Windows PowerShell, utilisez une commande telle que la suivante :

Ajouter-SPSolution - LiteralPath MySolution.wsp

Une fois l'opération d'ajout est terminée, le package s'affiche dans la page gestion des solutions du site Administration centrale. Bien que vous avez téléchargé le fichier de package, ses fonctionnalités ne sont pas encore prêtes à l'emploi. À ce stade, les fichiers de solution n'ont pas été installés sur chaque serveur SharePoint.

Maintenant que vous avez ajouté votre paquet au magasin de solutions de batterie de serveurs, vous êtes prêt à déployer sur la batterie de serveurs. Il existe deux façons vous pouvez déployer un package à partir du magasin de la ferme : déploiement local et par un travail du minuteur.

Un déploiement local installe les fichiers de solution sur un seul serveur dans la batterie de serveurs. Vous ne pouvez faire ce type de déploiement à l'aide de la ligne de commande. Cela n'affectera seulement le serveur sur lequel elle s'exécutera. Vous ne serez pas en mesure d'utiliser votre solution jusqu'à ce qu'elle est déployée sur l'ensemble des serveurs de la batterie. Par conséquent, vous devrez répéter le processus de déploiement sur chaque serveur.

Type de déploiement le plus courant utilise le Service du minuteur SharePoint. Vous pouvez déployer cette manière en utilisant la ligne de commande ou le site Web Administration centrale. Lorsque vous démarrez le déploiement, SharePoint crée un travail de minuteur s'exécute sur chaque serveur de la batterie. Cela a le même effet que d'effectuer des déploiements locales sur chaque serveur.

En plus qui vous permet de déployer en une seule étape, déploiements emploi minuterie également automatisent le processus de redémarrage du processus de travail IIS. Vous devez faire cela pour reconnaître correctement les fichiers de la nouvelle solution SharePoint. Il pourrait y avoir une brève interruption lors du redémarrage du processus de travail IIS, mais il ne devrait pas durer plus de quelques secondes dans la plupart des cas.

Pour effectuer un déploiement de batterie à partir de la ligne de commande, vous pouvez utiliser l'option - deploysolution sur l'outil STSADM ou l'applet de commande Install-SPSolution dans Windows PowerShell. (Notez que l'applet de commande Windows PowerShell est appelée Install-SPSolution, pas déployer-SPSolution.)

Ces deux commandes ont un - drapeau local pour effectuer un déploiement local. Pour utiliser un travail du minuteur qui s'exécutera à un moment donné, utilisez le - option de temps sur chaque commande. Pour utiliser un travail du minuteur s'exécute immédiatement après avoir entré la commande, utilisez le - option immédiate sur STSADM ou laissez les - options locales - temps et hors de la commande de Windows PowerShell.

Vous pouvez spécifier plusieurs autres options lors du déploiement d'une solution de batterie. Voici quelques-unes des plus importantes :

  • **Application Web :**Certaines solutions ont des ressources que vous devrez déployer au sein de la structure de répertoire d'application Web IIS. Lorsque vous déployez une solution, vous pouvez sélectionner un ensemble d'applications Web pour destiner à ces ressources.
  • **Assemblées mondiales :**Si le package de solution contient des assemblys, que vous devez déployer pour le Global Assembly Cache (GAC), il y a une option qui vous empêche de se déployer sans le savoir un code entièrement fiable.
  • **AUTORITÉS DE CERTIFICATION :**Stratégies CAS contrôlent les autorisations accordées au code de confiance partielle en cours d'exécution dans la batterie de serveurs. Si un package de solution contient de nouvelles stratégies de CAS, vous devrez signaler ceci.

Vous pouvez également déployer une solution à partir du site Web Administration centrale. Sélectionnez Paramètres système dans le menu de gauche. Puis sélectionnez gérer les Solutions de batterie. Un paquet fraîchement ajouté apparaît avec l'état non déployé.

Cliquez sur le nom du package et vous verrez un écran avec des informations utiles sur le paquet, y compris si elle contient des éléments qui requièrent un traitement particulier pendant le déploiement, tels que les assemblys de confiance totale ou stratégies CAS. Cliquez sur le lien de déployer la Solution pour afficher un formulaire, que vous pouvez utiliser pour démarrer un travail du minuteur pour le déploiement. Vous ne pouvez effectuer des déploiements par le biais de l'interface Web.

Déploiement d'une solution en bac à sable à SharePoint est très différent de déployer une solution de batterie. Au lieu d'un Add suivi d'un déploiement, un déploiement sandbox se compose des étapes de déploiement et activer. Toutefois, à l'aide d'un bac à sable est un moyen efficace de solutions de test avant de les déployer live.

Steve Wright

Steve Wright est un cadre supérieur en gestion d'entreprise intelligence pour Sogeti USA LLC à Omaha, au Nebraska. Au cours des dernière plus de 20 ans, Wright a travaillé sur le contrôle du trafic aérien, financier, d'assurance et une multitude d'autres types de systèmes. Il a écrit et réalise des examens techniques pour de nombreux titres précédents portant sur les produits Microsoft, notamment Windows, SharePoint, SQL Server et BizTalk.

Corey Erkes

Corey Erkes est consultant manager Sogeti USA LLC à Omaha, au Nebraska. Erkes a travaillé avec un large éventail de sociétés à différents points du cycle de vie de leurs implémentations de SharePoint. Il est également l'un des membres fondateurs du groupe d'utilisateurs SharePoint Omaha.

© 2012 Apress Inc. Tous droits réservés. Imprimé avec la permission de Apress. Copyright 2012. « Pro SharePoint 2012 gouvernance » par Steve Wright et Corey Erkes. Pour plus d'informations sur ce titre et autres ouvrages semblables, s'il vous plaît visitez apress.com.

Contenu associé