Gestion du cycle de vie des applications dans SharePoint 2010

Découvrez comment planifier et gérer la Gestion du cycle de vie des applications dans les projets Microsoft SharePoint 2010 à l’aide de Microsoft Visual Studio 2010 et Microsoft SharePoint Designer 2010. Découvrez également les éléments à prendre en compte lors de la configuration d’environnements de développement en équipe, de l’établissement de processus de gestion des mises à niveau et de la création d’un modèle de développement SharePoint standard.

Dernière modification : lundi 1 août 2011

S’applique à : Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Dans cet article
Introduction à la Gestion du cycle de vie des applications dans SharePoint 2010
Gestion du cycle de vie des applications SharePoint : présentation
Packages de solutions et outils de développement SharePoint
Utilisation de SharePoint Designer 2010 comme outil de développement
Importation de packages de solutions dans Visual Studio 2010
Environnement de développement en équipe pour SharePoint 2010 : présentation
Configuration d’un environnement de développement en équipe pour SharePoint 2010
Modèles de Gestion du cycle de vie des solutions dans SharePoint 2010
Conclusion
Ressources supplémentaires

Auteur :  Vesa Juvonen, Microsoft Corporation | Chris Keyser, Microsoft Corporation

Sommaire

• Introduction à la Gestion du cycle de vie des applications dans SharePoint 2010

• Gestion du cycle de vie des applications SharePoint : présentation

• Packages de solutions et outils de développement SharePoint

• Utilisation de SharePoint Designer 2010 comme outil de développement

• Importation de packages de solutions dans Visual Studio 2010

• Environnement de développement en équipe pour SharePoint 2010 : présentation

• Configuration d’un environnement de développement en équipe pour SharePoint 2010

• Modèles de Gestion du cycle de vie des solutions dans SharePoint 2010

• Conclusion

• Ressources supplémentaires

Introduction à la Gestion du cycle de vie des applications dans SharePoint 2010

La plateforme de développement Microsoft SharePoint 2010, qui comprend Microsoft SharePoint Foundation 2010 et Microsoft SharePoint Server 2010, offre de nombreuses fonctionnalités pour vous aider à développer, déployer et mettre à jour des personnalisations et des fonctionnalités personnalisées pour vos sites SharePoint. Les activités qui tirent parti de ces fonctionnalités appartiennent toutes à la catégorie de Gestion du cycle de vie des applications.

Les considérations essentielles lors de l’établissement de processus de Gestion du cycle de vie des applications incluent non seulement les pratiques de développement et de test que vous appliquez avant le déploiement initial d’une personnalisation, mais également les processus que vous devez implémenter pour gérer les mises à jour et intégrer les personnalisations et fonctionnalités personnalisées dans une batterie existante. Cet article traite des fonctionnalités et outils à votre disposition lors de l’implémentation d’un processus de Gestion du cycle de vie des applications dans une batterie SharePoint et souligne certains aspects spécifiques à prendre en considération lors de la création et de l’affinage de votre processus de Gestion du cycle de vie des applications pour le développement SharePoint.

Cet article suppose que chaque équipe de développement développera un processus de Gestion du cycle de vie des applications unique et adapté à sa taille et à ses besoins. Les instructions qu’il contient sont par conséquent d’ordre général. Toutefois, il suppose également que quelles que soient la taille de votre équipe et la nature spécifique de vos solutions personnalisées, vous devrez répondre à certaines exigences similaires et utiliser des fonctionnalités et des outils communs à tous les développeurs SharePoint. Les instructions fournies dans cet article vous aideront à créer un modèle de développement qui tire parti de tous les avantages offerts par la plateforme SharePoint 2010 et répond aux besoins de votre organisation.

Gestion du cycle de vie des applications SharePoint : présentation

Bien que les détails spécifiques à votre processus de Gestion du cycle de vie des applications SharePoint 2010 puissent différer en fonction des exigences de votre organisation, la plupart des équipes de développement suivent le même ensemble général d’étapes. La Figure 1 illustre un exemple de processus de Gestion du cycle de vie des applications pour un déploiement de SharePoint 2010 à grande ou moyenne échelle. Bien évidemment, le processus et les tâches requises dépendent de la taille du projet.

Figure 1. Exemple de processus de Gestion du cycle de vie des applications

Voici les étapes spécifiques du processus illustré à la Figure 1 (voir la légende 1-10 appropriée) :

1. Quelqu’un (par exemple un responsable de projet ou un responsable du développement) recueille les exigences initiales et les convertit en tâches.

2. Les développeurs utilisent Microsoft Visual Studio Team Foundation Server 2010 ou d’autres outils pour effectuer le suivi de l’avancement du développement et stocker le code source personnalisé.

3. Le code source étant stocké à un emplacement centralisé, vous pouvez créer des builds automatisées à des fins d’intégration et de test d’unité. Vous pouvez également automatiser les activités de test afin d’accroître la qualité globale des personnalisations.

4. Une fois que les solutions personnalisées ont satisfait aux tests d’acceptation, votre équipe de développement peut continuer avec l’environnement de pré-production ou d’assurance de la qualité.

5. L’environnement de pré-production doit ressembler le plus possible à l’environnement de production. Cela signifie souvent qu’il doit posséder le même niveau de correctifs et les mêmes configurations. Cet environnement de pré-production vous permet de vérifier que vos solutions personnalisées fonctionneront en production.

6. De temps en temps, copiez la base de données de production dans l’environnement de pré-production, de manière à pouvoir imiter les actions de mise à niveau qui seront exécutées dans l’environnement de production.

7. Une fois que les personnalisations ont été vérifiées dans l’environnement de pré-production, elles sont déployées soit directement en production, soit dans un environnement de production intermédiaire puis en production.

8. Une fois les personnalisations déployées en production, elles sont exécutées contre la base de données de production.

9. Les utilisateurs finaux travaillent dans l’environnement de production et fournissent des commentaires et des idées concernant les différentes fonctionnalités. Les problèmes et bogues sont signalés et suivis par le biais de processus de suivi et de rapport établis.

10. Les commentaires, bogues et autres problèmes dans l’environnement de production sont convertis en exigences, qui sont classées par ordre de priorité et converties en tâches de développement. La Figure 2 illustre la façon dont plusieurs équipes de développeurs peuvent utiliser et traiter les rapports de bogues et les demandes de modification fournis par les utilisateurs finaux de l’environnement de production. Le modèle de la Figure 2 montre également comment les équipes de développement peuvent coordonner leurs packages de solutions. Par exemple, il se peut que l’équipe d’infrastructure et l’équipe de développement de fonctionnalités suivent des modèles de contrôle de version distincts qui doivent être coordonnés lors du suivi des bogues et des modifications.

    Figure 2. Gestion des modifications impliquant plusieurs équipes de développeurs

    

Intégration des environnements de test et de vérification de build dans un processus de Gestion du cycle de vie des applications SharePoint 2010

Dans les projets à grande échelle, un personnel d’assurance de la qualité peut utiliser une batterie supplémentaire de vérification de build ou de test d’acceptation utilisateur pour tester et vérifier les builds dans un environnement qui ressemble plus étroitement à l’environnement de production. En général, une batterie de vérification de build contient plusieurs serveurs, afin de s’assurer que les solutions personnalisées sont déployées correctement. La Figure 3 illustre un modèle possible de mise en rapport entre les environnements de test et d’intégration du développement, les batteries de vérification de build et les environnements de production. Dans ce modèle particulier, la batterie de pré-production ou d’assurance de la qualité et la batterie de production permutent après chaque build. Ce modèle permet de limiter les temps d’arrêt liés à la maintenance des environnements.

Figure 3. Modèle de mise en rapport en les environnements de test et d’intégration du développement

Intégration de SharePoint Designer 2010 dans un processus de Gestion du cycle de vie des applications SharePoint 2010

Microsoft SharePoint Designer 2010 est un autre élément important à prendre en considération dans votre modèle de Gestion du cycle de vie des applications. SharePoint 2010 est une excellente plateforme pour les solutions sans code, qui peuvent être créées puis déployées directement dans l’environnement de production à l’aide de SharePoint Designer 2010. Ces personnalisations sont stockées dans la base de données de contenu, et non dans votre référentiel de code source. Les activités générales de conception et leurs interactions avec les activités de développement sont un autre aspect à prendre en considération. Allez-vous créer des mises en page directement dans votre environnement de production ou allez-vous les déployer dans le cadre de vos solutions empaquetées ? Ces deux options offrent des avantages et des inconvénients.

Votre modèle de Gestion du cycle de vie des applications spécifique dépend entièrement des solutions personnalisées et des personnalisations que vous prévoyez d’effectuer, mais également de vos propres stratégies. Il n’est pas obligatoire que votre processus de Gestion du cycle de vie des applications soit aussi complexe que celui décrit dans cette section. Toutefois, vous devez établir un modèle de Gestion du cycle de vie des applications rigoureux durant la phase initiale du processus, lors de la planification et de la création de votre environnement de développement et avant de commencer à créer vos solutions personnalisées.

Nous allons maintenant examiner les outils et fonctionnalités spécifiques au développement SharePoint 2010 dont vous disposez pour vous aider à choisir un modèle de Gestion du cycle de vie des applications SharePoint adapté à votre équipement de développement.

Packages de solutions et outils de développement SharePoint

L’un des principaux avantages offerts par la plateforme de développement SharePoint 2010 est le fait qu’elle permet d’enregistrer des sites en tant que packages de solutions. Un package de solution est un package déployable et réutilisable stocké dans un fichier CAB avec une extension .wsp. Vous pouvez créer un package de solution à l’aide de l’interface utilisateur de SharePoint 2010 dans le navigateur, de SharePoint Designer 2010 ou de Microsoft Visual Studio 2010. Dans les interfaces utilisateur du navigateur et de SharePoint Designer 2010, les packages de solutions portent également le nom de modèle. Cette flexibilité vous permet de créer et de concevoir des structures de sites dans un navigateur ou dans SharePoint Designer 2010, puis d’importer ces personnalisations dans Visual Studio 2010 afin d’effectuer des tâches de développement approfondies. Ce processus est illustré à la Figure 4.

Figure 4. Flux d’outils de développement SharePoint

Une fois les personnalisations terminées, vous pouvez déployer votre package de solution dans SharePoint afin de l’utiliser. Après avoir modifié la structure de site existante à l’aide d’un navigateur, vous pouvez recommencer le cycle en enregistrant le site mis à jour en tant que package de solution.

Cette interaction entre les outils vous permet également d’utiliser d’autres outils. Vous pouvez par exemple concevoir un processus de flux de travail dans Microsoft Visio 2010 puis l’importer vers SharePoint Designer 2010 et, à partir de là, vers Visual Studio 2010. Pour obtenir des instructions sur la façon de concevoir et d’importer un processus de flux de travail, voir Créer, importer et exporter des flux de travail SharePoint dans Visio.

Pour plus d’informations sur la création de packages de solutions dans SharePoint Designer 2010, voir Enregistrer un site SharePoint en tant que modèle. Pour plus d’informations sur la création de packages de solutions dans Visual Studio 2010, voir Creating SharePoint Solution Packages.

Utilisation de SharePoint Designer 2010 comme outil de développement

SharePoint Designer 2010 diffère de Microsoft Office SharePoint Designer 2007 dans le sens où il n’est plus axé sur la page, mais sur la fonctionnalité. L’interface utilisateur améliorée procure davantage de flexibilité dans la création et la conception de différentes fonctionnalités. Elle offre de puissants outils pour la création d’applications complètes, réutilisables et centrées sur les processus. Pour plus d’informations sur les nouvelles fonctionnalités offertes par SharePoint Designer 2010, voir Mise en route de SharePoint Designer.

Vous pouvez également utiliser SharePoint Designer 2010 pour modifier des composants modulaires développées avec Visual Studio 2010. Vous pouvez par exemple créer des composants WebPart et d’autres contrôles dans Visual Studio 2010, les déployer dans une batterie SharePoint, puis les modifier dans SharePoint Designer 2010.

Les principaux utilisateurs cibles de SharePoint Designer 2010 sont le personnel informatique et les travailleurs de l’information, qui peuvent recourir à cette application pour créer des personnalisations dans un environnement de production. Pour cette raison, vous devez adopter un modèle de Gestion du cycle de vie des applications pour votre environnement qui définit les genres de personnalisations qui adhèreront au processus de développement de Gestion du cycle de vie des applications complet et celles qui pourront être effectuées à l’aide de SharePoint Designer 2010. Les développeurs sont des utilisateurs cibles secondaires. Ils peuvent utiliser SharePoint Designer 2010 dans le cadre de leurs activités de développement, en particulier durant la création initiale des packages de personnalisations mais également pour effectuer rapidement des tâches de développement et de prototypage. Votre processus de Gestion du cycle de vie des applications doit également définir la place de SharePoint Designer 2010 dans le modèle de développement élargi.

L’une des particularités de SharePoint Designer 2010 est le fait que lorsque vous l’utilisez pour modifier des fichiers, toutes vos modifications sont stockées dans la base de données de contenu plutôt que dans le système de fichiers. Par exemple, si vous personnalisez une page maître pour un site spécifique à l’aide de SharePoint Designer 2010 et que vous concevez et déployez ensuite de nouveaux éléments de personnalisation dans un package de solution, les modifications ne sont pas disponibles pour le site qui contient la page maître personnalisées, car ce site utilise la version de la page maître stockée dans la base de données de contenu.

Pour limiter les complications telles que celle-ci, SharePoint Designer 2010 offre de nouvelles fonctionnalités qui vous permettent de contrôler l’utilisation de SharePoint Designer 2010 dans un environnement spécifique. Vous pouvez appliquer ces paramètres de contrôle au niveau de l’application Web ou de la collection de sites. Si vous désactivez une action au niveau de l’application Web, ce paramètre ne peut pas être modifié au niveau de la collection de sites.

SharePoint Designer 2010 donne accès aux paramètres suivants :

• autoriser l’ouverture du site dans SharePoint Designer 2010 ;

• autoriser la personnalisation des fichiers ;

• autoriser la personnalisation des pages maîtres et des pages de disposition ;

• autoriser les administrateurs de collection de sites à voir la structure d’URL des sites.

Notes

Ces paramètres sont ignorés si vous utilisez le compte d’administration de la batterie.

La fonction première de SharePoint Designer 2010 étant de personnaliser du contenu sur un site existant, le contrôle de code source n’est pas pris en charge. Par défaut, les pages que vous personnalisez à l’aide de SharePoint Designer 2010 sont stockées dans une bibliothèque SharePoint avec gestion de version. Cela permet de disposer d’une prise en charge simple du contrôle de version, mais pas d’un contrôle de code source complet.

Importation de packages de solutions dans Visual Studio 2010

Lorsque vous enregistrez un site comme package de solution dans le navigateur (à partir de la page Enregistrer comme modèle dans Paramètres du site), SharePoint 2010 stocke le site en tant que fichier de package de solution (.wsp) et le place dans la Galerie Solutions de cette collection de sites. Vous pouvez ensuite télécharger le package de solution à partir de la Galerie Solutions et l’importer dans Visual Studio 2010 à l’aide du modèle Importer le package de solution SharePoint, comme illustré à la Figure 5.

Figure 5. Modèle Importer le package de solution SharePoint

Les packages de solutions SharePoint 2010 contiennent de nombreuses améliorations qui tirent parti de nouvelles fonctionnalités disponibles dans son infrastructure de fonctionnalités. La liste suivante répertorie certains des nouveaux éléments de fonctionnalités susceptibles de vous aider à gérer vos projets de développement et mises à niveau.

• SourceVersion pour WebFeature et SiteFeature

• Élément de fonctionnalité WebTemplate

• Élément de fonctionnalité PropertyBag

• $ListId:Lists

• Élément de fonctionnalité WorkflowAssociation

• Attribut CustomSchema sur ListInstance

• Dépendances de solutions

Après avoir importé votre projet, vous pouvez commencer à le personnaliser comme bon vous semble.

Notes

Cette fonctionnalité étant basée sur l’élément WebTemplate, qui est lui-même basé sur une définition de site correspondante, le package de solution résultant contiendra des définitions pour tout le contenu du site. Pour plus d’informations sur la création et l’utilisation de modèles Web ,voir Modèles Web.

Visual Studio 2010 prenant en charge le contrôle de code source (comme illustré à la Figure 6), vous pouvez stocker le code source de vos personnalisations à un emplacement centralisé plus sûr et sécurisé. Par ailleurs, il simplifie le partage des personnalisations parmi les développeurs.

Figure 6. Contrôle de code source Visual Studio 2010

La manière spécifique par laquelle vos développeurs accèdent à ce code source et interagissent les uns avec les autres dépend de la structure de votre environnement de développement en équipe. La section suivante de cet article traite des éléments à prendre en considération lors de la conception d’un environnement de développement en équipe pour SharePoint 2010.

Environnement de développement en équipe pour SharePoint 2010 : présentation

Comme dans tout processus de planification de Gestion du cycle de vie des applications, votre planification SharePoint 2010 doit comprendre les étapes suivantes :

1. Identifier et créer un processus pour initier les projets.

2. Identifier et implémenter un système de contrôle de version pour votre code source et autres ressources déployées.

3. Planifier et implémenter des stratégies de contrôle de version.

4. Identifier et créer un processus pour le suivi et la création de rapports concernant les éléments de travail et les anomalies.

5. Rédiger la documentation relative à vos exigences et plans.

6. Identifier et créer un processus pour les builds automatisées et l’intégration continue.

7. Normaliser votre modèle de développement à des fins de répétition.

Microsoft Visual Studio Team Foundation Server 2010 (illustré à la Figure 7) constitue une bonne plateforme pour une grande partie de ces éléments de votre modèle de Gestion du cycle de vie des applications.

Figure 7. Visual Studio 2010 Team Foundation Server

Une fois que vous avez établi votre modèle de développement en équipe, vous devez choisir un ensemble d’outils ou Microsoft Visual Studio Team Foundation Server 2010 pour gérer votre développement. Microsoft Visual Studio Team Foundation Server 2010 fournit une intégration directe à Visual Studio 2010 et peut être utilisé pour gérer votre processus de développement de manière efficace. Il offre de nombreuses fonctionnalités, mais la façon dont vous l’utiliserez dépendra de vos projets.

Vous pouvez recourir à Microsoft Visual Studio Team Foundation Server 2010 pour les activités suivantes :

• Suivi d’éléments de travail et signalement de l’avancement de votre développement. Microsoft Visual Studio Team Foundation Server 2010 fournit des outils pour créer et modifier des éléments de travail délivrés non seulement à partir de Visual Studio 2010, mais également à partir du client Web Visual Studio 2010.

• Stockage de tout le code source de vos solutions personnalisées.

• Journalisation des bogues et défauts.

• Création, exécution et gestion de vos tests à l’aide de fonctionnalités de test complètes.

• Activation de l’intégration continue de votre code à l’aide des fonctionnalités de builds automatisées.

Microsoft Visual Studio Team Foundation Server 2010 propose également une option d’installation de base qui installe toutes les fonctionnalités requises pour le contrôle de code source et les builds automatisées. S’agissant des fonctionnalités de Microsoft Visual Studio Team Foundation Server 2010 les plus couramment utilisées, cette option facilite la configuration de votre environnement de développement.

Configuration d’un environnement de développement en équipe pour SharePoint 2010

SharePoint 2010 doit être installé sur un ordinateur de développement afin de tirer pleinement parti de ses fonctionnalités de développement. Si vous développez uniquement des applications distantes, telles que des solutions qui utilisent des services Web SharePoint, le modèle objet client ou REST, vous pourriez éventuellement développer des solutions sur un ordinateur où SharePoint 2010 n’est pas installé. Toutefois, même dans ce cas, la productivité de vos développeurs sera moindre car ils ne pourront pas tirer parti de toute l’expérience de débogage disponible lorsque SharePoint 2010 est installé directement sur l’ordinateur de développement.

La conception de votre environnement de développement dépend de la taille et des besoins de votre équipe de développement. Votre choix de système d’exploitation a également un impact majeur sur la conception globale de votre processus de développement en équipe. Trois principales options s’offrent à vous pour la création de vos environnements de développement :

1. Vous pouvez exécuter SharePoint 2010 directement sur le système d’exploitation client de votre ordinateur. Cette option est disponible uniquement lorsque vous utilisez la version 64 bits de Windows 7, Windows Vista Service Pack 1 ou Windows Vista Service Pack 2.

2. Vous pouvez utiliser l’option de démarrage sur le disque dur virtuel, qui signifie que vous démarrez votre ordinateur portable à l’aide du système d’exploitation sur le disque dur virtuel. Cette option est disponible uniquement lorsque vous utilisez Windows 7 comme système d’exploitation principal.

3. Vous pouvez utiliser les fonctionnalités de virtualisation, auquel cas de nombreuses options sont disponibles. Toutefois, d’un point de vue opérationnel, l’option susceptible d’offrir la plus grande facilité d’implémentation est un environnement virtualisé centralisé qui héberge l’environnement de développement de chaque développeur.

Les sections suivantes examinent plus en détail chacune de ces trois options.

SharePoint 2010 sur un système d’exploitation client

Si vous utilisez la version 64 bits de Windows 7, Windows Vista Service Pack 1 ou Windows Vista Service Pack 2, vous pouvez installer SharePoint Foundation 2010 ou SharePoint Server 2010. Pour plus d’informations sur l’installation de SharePoint 2010 sur les systèmes d’exploitation pris en charge, voir Configuration de l’environnement de développement pour SharePoint 2010 sur Windows Vista, Windows 7 et Windows Server 2008.

La Figure 8 illustre comment opèrerait un ordinateur exécutant un système d’exploitation client dans un environnement de développement en équipe.

Figure 8. Ordinateur exécutant un système d’exploitation client dans un environnement de développement en équipe

L’un des avantages offerts par cette approche est que vous pouvez tirer pleinement parti de votre matériel existant qui exécute l’un des systèmes d’exploitation clients cibles. Vous pouvez également tirer parti de configurations, ressources d’entreprise et domaines préexistants pris en charge par votre entreprise. Le support informatique supplémentaire nécessaire pourrait ainsi être faible, voire nul. De plus, vos développeurs ne constateraient aucun délai (comme lors du démarrage d’un ordinateur virtuel ou de la connexion à distance à un environnement) lors de l’accès à leur environnement de développement.

Néanmoins, si vous adoptez cette approche, vous devez vous assurer que vos développeurs ont accès à des ressources matérielles suffisantes. Dans tout environnement de développement, vous devez utiliser un ordinateur doté d’un processeur compatible x64 et d’au moins 2 Gigaoctets (Go) de RAM pour installer et exécuter SharePoint Foundation 2010 ; pour des raisons de performances, il est préférable de disposer de 4 Go de RAM. Vous devez utiliser un ordinateur disposant de 6 à 8 Go de RAM pour installer et exécuter SharePoint Server 2010.

L’un des inconvénients de cette approche est que vos environnements ne seront pas gérés de manière centralisée et qu’il sera difficile de garantir la synchronisation de toutes vos exigences environnementales reposant sur le projet. Il est également conseillé d’écrire des fichiers de commandes qui démarrent et arrêtent certains des services liés à SharePoint, de sorte que lorsque vos développeurs ne travaillent pas avec SharePoint 2010, ces services ne consomment pas de ressources et ne dégradent pas les performances de leurs ordinateurs.

L’absence de maintenance centralisée pourrait nuire à la productivité des développeurs d’autres manières. Cette approche pourrait par exemple ne pas convenir si votre équipe travaille sur un grand projet Microsoft SharePoint Online qui développe des solutions personnalisées pour plusieurs services (par exemple, les équivalents de http://intranet, http://mysite, http://teams, http://secure, http://search, http://partners et http://www.internet.com) et déploie ces solutions dans plusieurs pays ou régions. Si vous développez sur un ordinateur qui exécute un système d’exploitation client dans un domaine d’entreprise, chaque ordinateur de développement a son propre nom (et chaque nom de domaine local est différent, par exemple http://dev1 ou http://dev2). Si chaque développeur implémente des fonctionnalités personnalisées pour plusieurs services, vous devez utiliser différents numéros de ports afin de différentier chaque service (par exemple, http://dev1 pour http://intranet et http://dev1:81 pour http://mysite). Si tous vos développeurs utilisent les mêmes projets Visual Studio 2010, l’URL de débogage de projet doit être modifiée manuellement chaque fois qu’un développeur extrait la version la plus récente d’un projet de votre référentiel de code source. Cette étape manuelle supplémentaire pourrait nuire à la productivité des développeurs et réduire l’efficacité des scripts que vous avez rédigés pour la configuration des environnements de développement, car les différents environnements ne sont pas normalisés. Une certaine forme de centralisation avec la virtualisation est préférable pour les projets de développement d’entreprise à grande échelle.

SharePoint 2010 sur Windows 7 et démarrage sur disque dur virtuel

Si vous utilisez Windows 7, vous pouvez également créer un disque dur virtuel à partir d’une image existante de Windows Server 2008 sur laquelle SharePoint 2010 est installé dans Windows Hyper-V, puis configurer Windows 7 avec BDCEdit.exe afin qu’il démarre directement le système d’exploitation sur le disque dur virtuel. Pour en savoir plus sur ce genre de configuration, voir Déployer Windows sur un disque dur virtuel avec démarrage natif et Démarrer à partir d’un disque dur virtuel dans Win 7.

La Figure 9 illustre comment opèrerait un ordinateur exécutant Windows 7 et démarrant sur un disque dur virtuel dans un environnement de développement en équipe.

Figure 9. Windows 7 et démarrage sur disque dur virtuel dans un environnement d’équipe

En termes de flexibilité, cette approche offre l’avantage de pouvoir disposer de plusieurs environnements dédiés pour un même projet, ce qui vous permet d’isoler chaque environnement de développement. Vos développeurs ne créeront pas accidentellement de références croisées à des artefacts dans leurs projets et ils pourront créer des environnements dépendant du projet.

Toutefois, cette option exige un matériel conséquent, car vous utilisez le matériel et les ressources disponibles directement sur vos ordinateurs.

SharePoint 2010 dans les environnements virtualisés centralisés

Dans un environnement virtualisé centralisé, vous hébergez vos environnements de développement dans un emplacement centralisé et les développeurs accèdent à ces environnements par le biais de connexions à distance. Cela signifie que vous utilisez Windows Hyper-V à l’emplacement centralisé et que vous copiez un disque dur virtuel pour chaque développeur. Chaque disque dur virtuel est configuré de façon à être accessible à partir du réseau d’entreprise ; ainsi, dès son démarrage, il est accessible par le biais de connexions distantes.

La Figure 10 illustre le mode opératoire d’un environnement de développement en équipe virtualisé et centralisé

Figure 10. Environnement de développement en équipe virtualisé et centralisé

L’un des avantages offerts par cette approche est le fait que les exigences en matériel de chaque ordinateur de développement sont relativement faibles car le travail réel a lieu dans un environnement centralisé. Les développeurs pourraient même utiliser des ordinateurs disposant d’1 Go de RAM comme clients et se connecter à distance à l’emplacement centralisé. Par ailleurs, la gestion des environnements s’effectue facilement depuis un emplacement centralisé, ce qui simplifie les ajustements en cas de besoin.

Votre hôte centralisé doit disposer de ressources matérielles importantes, mais les développeurs peuvent facilement démarrer et arrêter ces environnements. Cela vous permet d’utiliser le matériel que vous avez alloué à vos environnements de développement de manière plus efficace. En outre, cette approche permet de disposer d’une plateforme pour les environnements de test étendus pour votre code personnalisé (tels que les batteries à plusieurs serveurs).

Après avoir configuré votre environnement de développement en équipe, vous pouvez commencer à tirer parti des fonctionnalités de déploiement et de mise à niveau offertes par le nouveau modèle d’empaquetage de solution dans SharePoint 2010. Les sections suivantes décrivent comment tirer parti de ces nouvelles fonctionnalités dans votre modèle de Gestion du cycle de vie des applications.

Modèles de Gestion du cycle de vie des solutions dans SharePoint 2010

Le modèle d’empaquetage de solution SharePoint 2010 fournit de nombreuses fonctionnalités utiles qui vous aideront à planifier le déploiement de solutions personnalisées et la gestion du processus de mise à niveau. Vous pouvez implémenter le contrôle de version d’assembly en appliquant des redirections de liaisons dans votre fichier de configuration d’application Web. Vous pouvez également appliquer le contrôle de version à vos mises à niveau de fonctionnalités ; les actions de mise à niveau de fonctionnalité vous permettent de gérer les modifications qui seront nécessaires sur vos sites existants. Ces actions de mise à niveau peuvent être gérées de manière déclarative ou par programme.

Le modèle objet de requête de mise à niveau de fonctionnalité vous permet de créer des requêtes dans votre code qui recherchent, sur vos sites existants, des fonctionnalités pouvant être mises à niveau. Vous pouvez utiliser ce modèle objet pour obtenir des informations pertinentes concernant toutes les fonctionnalités et versions de fonctionnalités déployées sur vos sites SharePoint 2010. Dans votre fichier manifeste de solution, vous pouvez également configurer le type de recyclage IIS (Internet Information Services) à effectuer durant la mise à niveau de solution.

Les sections suivantes décrivent en détail ces fonctionnalités et comment vous pouvez les utiliser.

Utilisation de l’élément d’assembly BindingRedirect avec des assemblys SharePoint 2010

L’élément de fonctionnalité BindingRedirect peut être ajouté à votre fichier de configuration d’application Web. Il vous permet de rediriger à partir de versions antérieures d’assemblys installés vers de nouvelles versions. La Figure 11 montre comment la configuration XML du fichier manifeste de solution fait en sorte que SharePoint ajoute des règles de redirection de liaison au fichier de configuration d’application Web. Ces règles transfèrent toute référence à la version 1.0 de l’assembly vers la version 2.0. Ceci est requis dans votre fichier manifeste de solution si vous mettez à niveau une solution personnalisée qui utilise le contrôle de version d’assembly et s’il existe des instances existantes de la solution et de l’assembly sur vos sites.

Figure 11. Règles de redirection de liaison dans un fichier manifeste de solution

Il est recommandé d’utiliser le contrôle de version d’assembly car cela facilite le suivi des versions d’une solution déployées dans vos environnements de production.

Contrôle de version de fonctionnalité SharePoint 2010

La prise en charge du contrôle de version de fonctionnalité dans SharePoint 2010 offre de nombreuses fonctionnalités auxquelles vous pouvez faire appel lors de la mise à niveau des fonctionnalités. Par exemple, vous pouvez utiliser la propriété SPFeature.Version pour déterminer les versions d’une fonctionnalité qui sont déployées sur votre batterie, et par conséquent identifier les fonctionnalités qui doivent être mises à niveau. Pour un exemple de code qui montre comment procéder, voir Version.

Le contrôle de version de fonctionnalité dans SharePoint 2010 vous permet également de définir une valeur pour la propriété SPFeatureDependency.MinimumVersion afin de gérer les dépendances de fonctionnalités. Vous pouvez par exemple utiliser la propriété MinimumVersion pour vous assurer qu’une version particulière d’une fonctionnalité dépendante est activée. Il est possible d’ajouter ou de supprimer des dépendances de fonctionnalités dans chaque nouvelle version d’une fonctionnalité.

L’infrastructure de fonctionnalités de SharePoint 2010 a également amélioré le niveau de modèle objet afin de prendre en charge le contrôle de version de fonctionnalité plus facilement. Vous pouvez utiliser la méthode QueryFeatures pour extraire une liste de fonctionnalités et vous pouvez à la fois spécifier la version de fonctionnalité et indiquer si une fonctionnalité nécessite une mise à niveau. La méthode QueryFeatures renvoie une instance de SPFeatureQueryResultCollection, que vous pouvez utiliser pour accéder à toutes les fonctionnalités qui doivent être mises à jour. Cette méthode est disponible à partir de plusieurs étendues, car elle est accessible à partir des classes SPWebService, SPWebApplication, SPContentDatabase et SPSite. Pour plus d’informations sur cette méthode surchargée, voir QueryFeatures(), QueryFeatures(), QueryFeatures() et QueryFeatures(). Pour une vue d’ensemble du modèle objet de mise à niveau de fonctionnalité, voir Modèle objet de la mise à niveau de Composants fonctionnels.

La section suivante fournit une synthèse d’une grande partie des nouvelles actions de mise à niveau que vous pouvez appliquer lors de la mise à niveau d’une version d’une fonctionnalité vers une autre.

Actions de mise à niveau de fonctionnalité SharePoint 2010

Les actions de mise à niveau sont définies dans le fichier Feature.xml. La classe SPFeatureReceiver contient une méthode FeatureUpgrading que vous pouvez utiliser pour définir les actions à effectuer durant une mise à niveau. Cette méthode est appelée durant la mise à niveau de fonctionnalité lorsque le fichier Feature.xml de la fonctionnalité contient une ou plusieurs balises <CustomUpgradeAction>, comme indiqué dans l’exemple suivant.

<UpgradeActions>
  <CustomUpgradeAction Name="text">
    ...
  </CustomUpgradeAction>
</UpgradeActions>

Chaque action de mise à niveau personnalisée a un nom qui peut servir à différentier le code qui doit être exécuté dans le récepteur de fonctionnalité. Comme indiqué dans l’exemple suivant, vous pouvez paramétrer des instances d’actions personnalisées.

<Feature xmlns="https://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <!-- First action-->
      <CustomUpgradeAction Name="example">
        <Parameters>
          <Parameter Name="parameter1">Whatever</Parameter>
          <Parameter Name="anotherparameter">Something meaningful</Parameter>
          <Parameter Name="thirdparameter">additional configurations</Parameter>
        </Parameters>
      </CustomUpgradeAction>
      <!-- Second action-->
      <CustomUpgradeAction Name="SecondAction">
        <Parameters>
          <Parameter Name="SomeParameter1">Value</Parameter>
          <Parameter Name="SomeParameter2">Value2</Parameter>
          <Parameter Name="SomeParameter3">Value3</Parameter>
        </Parameters>
      </CustomUpgradeAction>
    </VersionRange>
  </UpgradeActions>
</Feature>

Cet exemple contient deux éléments CustomUpgradeAction, un nommé example et l’autre SecondAction. Les deux éléments ont différents paramètres, qui dépendent du code que vous avez rédigé pour le récepteur d’événements FeatureUpgrading. L’exemple suivant montre comment utiliser ces actions de mise à niveau et leurs paramètres dans votre code.

/// <summary>
/// Called when feature instance is upgraded for each of the custom upgrade actions in the Feature.xml file.
/// </summary>
/// <param name="properties">Feature receiver properties</param>
/// <param name="upgradeActionName">Upgrade action name</param>
/// <param name="parameters">Custom upgrade action parameters</param>

public override void FeatureUpgrading(SPFeatureReceiverProperties properties, 
                                        string upgradeActionName, 
                                        System.Collections.Generic.IDictionary<string, string> parameters)
{

    // Do not do anything, if feature scope is not correct.
    if (properties.Feature.Parent is SPWeb)
    {

        // Log that feature scope is incorrect.
        return;
    }

    switch (upgradeActionName)
    {
        case "example":
            FeatureUpgradeManager.UpgradeAction1(parameters["parameter1"], parameters["AnotherParameter"],
                                                 parameters["ThirdParameter"]);
            break;
        case "SecondAction":
            FeatureUpgradeManager.UpgradeAction1(parameters["SomeParameter1"], parameters["SomeParameter2"],
                                                 parameters["SomeParameter3"]);
            break;
        default:

            // Log that code for action does not exist.
            break;
    }
}

Vous pouvez avoir autant d’actions de mise à niveau que vous le souhaitez et les appliquer à des plages de versions. L’exemple suivant montre comment appliquer des actions de mise à niveau à des plages de versions d’une fonctionnalité.

<Feature xmlns="https://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange BeginVersion="1.0.0.0" EndVersion ="2.0.0.0">
      ...
    </VersionRange>
    <VersionRange BeginVersion="2.0.0.1" EndVersion="3.0.0.0">
      ...
    </VersionRange>
    <VersionRange BeginVersion="3.0.0.1" EndVersion="4.0.0.0">
      ...
    </VersionRange>
  </UpgradeActions>
</Feature>

L’action de mise à niveau AddContentTypeField peut servir à définir des champs supplémentaires pour un type de contenu existant. Elle offre également la possibilité de « pousser » ces modifications jusqu’aux instances enfants, ce qui constitue souvent le comportement préféré. Lors du déploiement initial d’un type de contenu dans une collection de sites, une définition de ce type est créée au niveau de la collection de sites. Si ce type de contenu est utilisé dans un sous-site ou une liste, une instance enfant du type de contenu est créée. Pour vous assurer que chaque instance du type de contenu spécifique est mise à jour, vous devez affecter à l’attribut PushDown la valeur true, comme indiqué dans l’exemple suivant.

<Feature xmlns="https://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <AddContentTypeField ContentTypeId="0x0101002b0e208ace0a4b7e83e706b19f32cab9"
                           FieldId="{ccbcd479-94c9-4f3a-95c4-58897da434fe}"
                           PushDown="True"/>
    </VersionRange>
  </UpgradeActions>
</Feature>

Pour plus d’informations sur l’utilisation de types de contenu par programme, voir Introduction aux types de contenu.

L’action de mise à niveau ApplyFeatureManifests peut servir à appliquer de nouveaux artefacts à un site SharePoint 2010 sans réactiver de fonctionnalités. Tout comme vous pouvez ajouter de nouveaux éléments à tout fichier elements.xml SharePoint, vous pouvez faire en sorte que SharePoint applique du contenu d’un fichier d’éléments spécifique à des sites où une fonctionnalité donnée est activée.

Vous pouvez utiliser cette action de mise à niveau si vous mettez à niveau une fonctionnalité existante dont le récepteur d’événements FeatureActivating effectue des actions que vous ne souhaitez plus exécuter sur des sites où la fonctionnalité est déployée. L’exemple suivant démontre comment inclure une action de mise à niveau dans un fichier Feature.xml.

<Feature xmlns="https://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <VersionRange EndVersion ="2.0.0.0">
      <ApplyElementManifests>
        <ElementManifest Location="AdditionalV2Fields\Elements.xml"/>
      </ApplyElementManifests>
    </VersionRange>
  </UpgradeActions>
</Feature>

En guise d’exemple d’utilisation de cette action de mise à niveau, on pourrait citer l’ajout de nouveaux fichiers .webpart à une fonctionnalité dans une collection de sites. Vous pouvez utiliser l’action de mise à niveau ApplyElementManifest pour ajouter ces fichiers sans réactiver la fonctionnalité. Un autre exemple concerne les mises en page, qui contiennent des instances de composants WebPart initiales définies dans la structure d’élément de fichier du fichier d’élément de fonctionnalité. Si vous réactivez cette fonctionnalité, vous obtiendrez des doublons de ces composants WebPart sur chacune des mises en page. Dans ce cas, vous pouvez utiliser l’élément ElementManifest de l’action de mise à niveau ApplyFeatureManifests pour ajouter de nouvelles mises en page à une collection de sites qui utilise la fonctionnalité sans réactiver celle-ci.

L’élément MapFile vous permet de mapper une demande d’URL à une autre URL. L’exemple suivant démontre comment inclure une action de mise à niveau dans un fichier Feature.xml.

<Feature xmlns="https://schemas.microsoft.com/sharepoint/">
  <UpgradeActions>
    <MapFile FromPath="Features\MapPathDemo_MapPathDemo\PageDeployment\MyExamplePage.aspx"
             ToPath="Features\MapPathDemo_MapPathDemo\PageDeployment\MyExamplePage2.aspx" />
  </UpgradeActions>
</Feature>

Le mappage d’URL de cette manière serait utile si vous deviez déployer une nouvelle version d’une page qui a été personnalisée à l’aide de SharePoint Designer 2010. La page personnalisée résultante serait présentée à partir de la base de données de contenu. Lorsque vous déploierez la nouvelle version de la page, celle-ci n’apparaîtra pas car le contenu de cette page provient de la base de données et non du système de fichiers. Vous pourriez contourner ce problème en utilisant l’élément MapFile pour rediriger les demandes portant sur l’ancienne version de la page vers la nouvelle version.

Il est important de bien comprendre que la méthode FeatureUpgrading est appelée pour chaque instance de fonctionnalité qui sera mise à jour. Si vous avez 10 sites dans votre collection de sites et que vous mettez à jour une fonctionnalité au niveau Web, le récepteur de fonctionnalité sera appelé 10 fois pour chaque contexte de site. Pour plus d’informations sur la façon d’utiliser ces nouveaux éléments de fonctionnalités déclaratifs, voir Modifications apportées à Feature.xml.

Mise à niveau de fonctionnalités SharePoint 2010 : procédure de haut niveau

Cette section décrit, à un haut niveau, comment mettre en pratique ces fonctionnalités de mise à niveau et de contrôle de version de fonctionnalité. Lorsque vous créez une version d’une fonctionnalité qui est déjà déployée sur une grande batterie SharePoint 2010, vous devez prendre en considération deux scénarios : ce qui se produit lorsque la fonctionnalité est activée sur un nouveau site et ce qui se produit sur les sites où la fonctionnalité existe déjà. Lorsque vous ajoutez du nouveau contenu à la fonctionnalité, vous devez d’abord mettre à jour toutes les définitions existantes et inclure des instructions pour la mise à niveau de la fonctionnalité là où elle est déjà déployée.

Imaginez par exemple que vous avez développé un type de contenu auquel vous devez ajouter une colonne de site personnalisée nommée City. Vous devez effectuer les étapes suivantes :

1. Ajouter un nouveau fichier d’élément à la fonctionnalité. Ce fichier d’élément définit la nouvelle colonne de site et modifie le fichier Feature.xml de façon à inclure le fichier d’élément.

2. Mettre à jour la définition existante du type de contenu dans le fichier d’élément de fonctionnalité existant. Cette mise à jour s’appliquera à tous les sites où la fonctionnalité est nouvellement déployée et activée.

3. Définir les actions de mise à niveau requises pour les sites existants. Dans ce cas, vous devez vous assurer que le fichier d’élément nouvellement ajouté pour la colonne de site supplémentaire est déployé et que la nouvelle colonne de site est associée aux types de contenu existants. Pour atteindre ces deux objectifs, vous devez ajouter les actions de mise à niveau ApplyFeatureManifests et AddContentTypeField à votre fichier Feature.xml.

Lorsque vous déployez la nouvelle version de la fonctionnalité sur des sites existants et que vous la mettez à niveau, les actions de mise à niveau sont appliquées aux sites une par une. Si vous avez défini des actions de mise à niveau personnalisées, la méthode FeatureUpgrading sera appelée autant de fois qu’il y a d’instances de la fonctionnalité activées dans votre batterie ou collection de sites.

La Figure 12 illustre l’interaction entre les différents composants de ce scénario lorsque vous effectuez la mise à niveau.

Figure 12. Composants d’une mise à niveau de fonctionnalité qui ajoute un nouvel élément à une fonctionnalité existante

Différentes versions d’une fonctionnalité peuvent être déployées sur différents sites. Dans ce cas, vous pouvez créer des plages de versions, qui définissent des actions spécifiques à effectuer lorsque vous effectuez une mise à niveau d’une version à une autre. Si aucune plage de versions n’est définie, toutes les actions de mise à niveau sont appliquées durant chaque mise à niveau.

La Figure 13 montre comment différentes actions de mise à niveau peuvent être appliquées à des plages de versions.

Figure 13. Application de différentes actions de mise à niveau à des plages de versions.

Dans cet exemple, si un site donné est mis à niveau directement de la version 1.0 vers la version 3.0, toutes les configurations sont appliquées car vous avez défini des actions spécifiques pour la mise à niveau de la version 1.0 vers la version 2.0 et de la version 2.0 vers la version 3.0. Vous avez également défini des actions qui sont appliquées quelle que soit la version de la fonctionnalité.

Instructions relatives à la conception du code pour la mise à niveau de fonctionnalités SharePoint 2010

Pour accroître la flexibilité de votre code, vous ne devez pas placer votre code de mise à niveau directement dans le récepteur d’événements FeatureUpgrading. Au lieu de cela, vous devez le mettre à un emplacement centralisé et y faire référence dans le récepteur d’événements, comme illustré à la Figure 14.

Figure 14. Gestionnaire de mise à niveau de fonctionnalité centralisé

En plaçant votre code de mise à niveau dans une classe utilitaire centralisée, vous augmentez la capacité de réutilisation et de test de votre code car vous pouvez effectuer les mêmes actions à plusieurs emplacements. Vous devez également vous efforcer de concevoir vos actions de mise à niveau personnalisées le plus génériquement possible, en faisant appel à des paramètres pour les rendre applicables à des scénarios de mise à niveau spécifiques.

Cycles de vie de solution : mise à niveau de solutions SharePoint 2010

Si vous mettez à niveau une solution de batterie (confiance totale), vous devez d’abord déployer la nouvelle version de votre package de solution dans une batterie.

Exécutez l’un des scripts suivants à partir d’une invite de commandes pour déployer des mises à jour dans une batterie SharePoint. Le premier exemple utilise l’outil en ligne de commande Stsadm.exe.

stsadm -o upgradesolution -name solution.wsp -filename solution.wsp

Le second exemple utilise l’applet de commande Windows PowerShell Update-SPSolution.

Update-SPSolution -Identity contoso_solution.wsp -LiteralPath c:\contoso_solution_v2.wsp -GACDeployment

Une fois la nouvelle version déployée, vous pouvez effectuer la mise à niveau proprement dite, qui exécute les actions de mise à niveau que vous avez définies dans vos fichiers Feature.xml.

Une mise à niveau de solution de batterie de serveurs peut être effectuée à l’échelle de la batterie ou à un niveau plus granulaire à l’aide du modèle objet. Une mise à niveau à l’échelle de la batterie s’effectue à l’aide de l’outil en ligne de commande Psconfig, comme indiqué dans l’exemple suivant.

psconfig -cmd upgrade -inplace b2b

Notes

Cet outil provoque un arrêt des services sur les sites existants. Durant la mise à niveau, toutes les instances de fonctionnalités dans la batterie pour lesquelles de nouvelles versions sont disponibles sont mises à niveau.

Vous pouvez également effectuer des mises à niveau pour certaines fonctionnalités au niveau du site à l’aide de la méthode Upgrade de la classe SPFeature. Cette méthode ne provoque aucun arrêt de service dans votre batterie, mais vous êtes responsable de la gestion de la mise à niveau de version à partir de votre code. Pour obtenir un exemple de code qui illustre comment utiliser cette méthode, voir SPFeature.Upgrade.

La mise à niveau d’une solution en bac à sable (sandbox) au niveau de la collection de sites est beaucoup plus simple. Il vous suffit de télécharger le package de solution SharePoint (fichier .wsp) qui contient les fonctionnalités mises à niveau. Si vous avez une version précédente d’une solution en bac à sable (sandbox) dans votre galerie de solutions et que vous téléchargez une nouvelle version, une option Mettre à niveau apparaît dans l’interface utilisateur, comme illustré à la Figure 15.

Figure 15. Mise à niveau d’une solution en bac à sable (sandbox)

Une fois que vous avez sélectionné l’option Mettre à niveau et que la mise à niveau a démarré, toutes les fonctionnalités de la solution en bac à sable (sandbox) sont mises à niveau.

Conclusion

Cet article a traité de certains aspects et exemples de conception de Gestion du cycle de vie des applications spécifiques à SharePoint 2010 et a énuméré et décrit les fonctionnalités et outils les plus importants que vous pouvez intégrer dans les processus de Gestion du cycle de vie des applications que vous choisissez d’établir dans votre entreprise. Le modèle d’empaquetage de solution et l’infrastructure de fonctionnalité de SharePoint 2010 procurent une flexibilité et une puissance que vous pouvez exploiter dans vos processus de Gestion du cycle de vie des applications.

Ressources supplémentaires

Pour plus d’informations, voir les ressources suivantes :

• Centre de ressources de Gestion du cycle de vie des applications | SharePoint 2010 (éventuellement en anglais)

• Développement en équipe dans SharePoint 2010

• Création de fichiers personnalisés et de fichiers non personnalisés dans Windows SharePoint Services 3.0

• Guide de l’administrateur et du développeur sur la sécurité d’accès du code dans SharePoint Server 2007

• ASP.NET par rapport à SharePoint : différences de développement

• Business Connectivity Services dans SharePoint Foundation

• Solutions en mode bac à sable

• Configuration de l’environnement de développement pour SharePoint 2010 sur Windows Vista, Windows 7 et Windows Server 2008

• Utilisation de Visual Studio pour le développement SharePoint

• Utilisation de SharePoint Designer pour le développement SharePoint

• Fonctionnalités de débogage et de journalisation dans SharePoint 2010

• Exemple MSDN : débogage et journalisation dans SharePoint 2010 (éventuellement en anglais)

• Blog d’équipe SharePoint : gestion des mises à niveau des solutions en bac à sable (sandbox) (éventuellement en anglais)

• Centre pour développeurs SharePoint