Gestion du cycle de vie des applications SharePoint
Applique des pratiques et des concepts communs de gestion du cycle de vie des applications (ALM) au développement d'applications avec les technologies SharePoint.
Provided by: Eric Charran, Microsoft Corporation
Collaborateurs : Vesa Juvonen, Microsoft Corporation | Steve Peschka, Microsoft Corporation
Important : cette rubrique traite des Compléments SharePoint hébergées automatiquement. Le programme d'aperçu des applications hébergées automatiquement a pris fin. Veuillez ignorer toutes les références aux compléments SharePoint auto-hébergées.
Vue d’ensemble de la gestion du cycle de vie des applications (ALM)
Microsoft SharePoint propose aux développeurs plusieurs options pour créer et déployer des applications basées sur les technologies SharePoint, pour les plateformes cloud hébergées ou publiques, mais aussi sur site. SharePoint offre plus de souplesse dans la forme que les applications peuvent prendre, ainsi que de nouvelles options pour se servir des technologies normalisées avec les applications. Bien que les fonctionnalités d'application et les options de déploiement offertes par le nouveau modèle d'application dans SharePoint fournissent aux développeurs un moyen efficace pour créer des applications immersives, ces derniers doivent être à même de tenir compte des considérations relatives à la qualité, aux tests et à la gestion du cycle de vie des applications dans le processus de développement. Cet article applique des pratiques et des concepts ALM communs au développement d'applications avec les technologies SharePoint.
Nouveautés
SharePoint établit un nouveau paradigme pour la mise en œuvre des applications. En raison de cette évolution en matière de développement d'applications avec les technologies SharePoint, les développeurs et les architectes doivent maîtriser les nouveaux modèles de développement d'application, pratiques et modèles de déploiement pour SharePoint. Il est important de noter que si le modèle d'application pour le développement de solutions avec SharePoint a changé, la plupart des modèles utilisés pour le développement de solutions (choix des technologies, techniques de mise en œuvre, etc.) vont dans le sens des technologies de développement d'applications web existantes.
Les ressources suivantes présentent les types d’applications qui peuvent être construits à l’aide des technologies SharePoint et qui contiennent des considérations pour les applications locales et cloud. Pour comprendre les options d’hébergement des compléments SharePoint, voir Choisir des modèles pour le développement et l’hébergement de votre complément SharePoint.
Par ailleurs, Microsoft conseille aux clients d’évaluer les technologies utilisées lors du développement d’applications avec SharePoint, car il existe un ensemble plus large de choix pour l’implémentation de solutions. Lors de la création d’applications, les clients peuvent se concentrer sur l’utilisation de technologies standard telles que HTML5 et JavaScript pour les couches de présentation et d’expérience utilisateur, tandis que les technologies OData et OAuth peuvent être utilisées pour l’accès par service aux services principaux, y compris SharePoint. Les clients doivent examiner attentivement si un code de confiance complet (c'est-à-dire des assemblages compilés déployés sur SharePoint) est nécessaire. bien que continuer à utiliser ce paradigme de développement, bien qu’il soit toujours valide et obligatoire dans certains cas, impose une surcharge importante sur le processus ALM.
Pour plus d’informations sur les nouvelles technologies de développement flexibles pour les applications sur SharePoint, voir Vue d’ensemble du développement SharePoint.
Avantages et modifications
Étant donné que les technologies de développement d'applications prises en charge par SharePoint offrent maintenant un ensemble de langages et d'architectures de programmation plus souple, les développeurs doivent adapter les pratiques ALM existantes en fonction des techniques de développement standard pour prendre en compte leur présence dans SharePoint. Des concepts tels que les tests, la création de builds, le déploiement et le contrôle de la qualité peuvent être élargis de façon à inclure le déploiement dans SharePoint sous la forme d'une application SharePoint. Autrement dit, bien que de nombreux développeurs soient habitués à rédiger et déployer des solutions de batterie de serveurs côté serveur qui étendent les capacités de base de SharePoint, les pratiques ALM communes du nouveau modèle de développement flexible facilité par les applications SharePoint doivent être appliquées au processus de mise en œuvre.
Tandis que les clients poursuivent la transition vers des mises en œuvre de SharePoint hébergées dans le cloud, les développeurs doivent comprendre comment étendre les concepts ALM de manière à inclure les environnements cibles de développement, de test et de déploiement situés à l'extérieur des frontières physiques de l'organisation. Il s'agit notamment d'évaluer la stratégie technologique afin de mener à bien le développement, le test et le déploiement des applications.
Les développeurs, tout comme les architectes, peuvent devenir experts en synthèse de solutions composées de plusieurs composants d'application recouvrant ou combinant différents types d'option d'hébergement. Au cours du processus d'adaptation, les procédures ALM doivent être appliquées unilatéralement aux applications. Par exemple, les développeurs peuvent avoir besoin de déployer une application qui englobe le déploiement de services sur site (à savoir, IIS, ASP.NET, MVC, WebAPI et WCF), Microsoft Azure, SharePoint et SQL Azure, tout en étant en mesure de tester les composants de l'application afin de vérifier la qualité ou de déterminer si des régressions ont été introduites par rapport à un build précédent. Ces exigences peuvent signifier un changement important dans la façon dont les développeurs et les équipes considèrent le processus de build et de déploiement quotidien, qui constitue une procédure bien connue pour les solutions sur site ou côté serveur.
Considérations relatives à l’équipe de développement
Pour les organisations comptant plus d'un architecte ou développeur d'applications, le développement en équipe pour SharePoint doit être soigneusement planifié de manière à obtenir des applications de très haute qualité tout en permettant une productivité suffisante des développeurs. La méthode de développement d'applications étant désormais plus souple, les équipes doivent être claires et confiantes, non seulement en ce qui concerne les modèles et les pratiques ALM, mais aussi concernant la façon dont chaque développeur rédige le code et veille à ce que seul du code de qualité intègre le processus de génération d'applications.
Il s'agit en premier lieu de sélectionner l'environnement de développement approprié. Le développement a traditionnellement été considéré comme une tâche distincte, menée sur des ordinateurs virtuels connectés à un référentiel de code commun offrant des fonctionnalités de build, de déploiement et de test, comme Visual Studio TFS 2012. TFS occupe toujours une place déterminante dans les stratégies ALM, intervenant au cœur du travail de développement, mais les équipes doivent envisager la manière de tirer parti de TFS en fonction des différents types d'option d'environnement de développement.
Selon l'environnement cible et le type de solution (à savoir les composants sur site et ceux hébergés dans des services ou une infrastructure cloud), les développeurs peuvent maintenant choisir parmi une combinaison de nouvelles options d'environnement de développement. Ces dernières proposent par exemple le modèle de site de développeur SharePoint, un client de développeur Office 365, ainsi que des options héritées, telles que le développement sur un ordinateur virtuel avec Hyper-V dans Windows 8 ou Windows Server 2012.
La section suivante décrit les considérations sur les environnements de développement pour les développeurs d'applications et les équipes de développement.
Considérations relatives aux environnements de développement
La sélection d'un environnement de développement doit reposer sur plusieurs facteurs. Ces considérations sont largement influencées par le type d'application en cours de développement, ainsi que par la plateforme cible de l'application. Traditionnellement, lors de la création d'applications pour SharePoint Server 2010, les développeurs configurent des ordinateurs virtuels et travaillent de leur côté. En effet, le déploiement de solutions de confiance totale peut requérir des redémarrages des dépendances SharePoint de base, telles qu'IIS, ce qui empêche plusieurs développeurs d'utiliser un seul environnement SharePoint. Les technologies de développement ayant évolué et les options offertes aux développeurs d'applications s'étant multipliées, les développeurs et les équipes doivent connaître les différents environnements de développement dont ils disposent. La figure 1 montre les environnements de développement et les outils, et indique quels types de solution peuvent être déployés dans les environnements cibles.
Figure 1. Composants et outils de l’environnement de développement
[
Philosophie de l'environnement de développement
En raison des investissements consentis concernant la façon de concevoir et de mettre en œuvre des applications à l'aide de SharePoint, les développeurs doivent chercher à déterminer s'il est nécessaire d'effectuer le développement avec du code côté serveur. Étant donné que les développeurs créent des applications qui utilisent le modèle hébergé sur le cloud, il s'avère moins utile de procéder à un développement s'appuyant sur des environnements virtualisés, en particulier pour SharePoint. Les développeurs doivent essayer de créer des solutions avec le modèle de développement à distance utilisant l'infrastructure basée sur le cloud existante (publique et privée). S'ils ont la possibilité de configurer des environnements de développement rapidement et facilement, sans avoir à créer ni à orchestrer de virtualisation, ils ont davantage de temps pour se concentrer sur la productivité et la qualité du développement, plutôt que sur la gestion de l'infrastructure.
La décision d'avoir recours à une instance virtualisée de SharePoint plutôt qu'au nouveau modèle de site de développement SharePoint dépend de la nécessité pour l'application de déployer et d'exécuter du code de confiance totale dans SharePoint. Si aucun code de confiance totale n'est requis, nous recommandons d'utiliser le modèle de site de développeur, qui figure sur les clients de développement Office 365 ou au sein de la mise en œuvre du SharePoint sur site d'une organisation. Les modèles de site de développeur sont conçus pour que les développeurs déploient des applications directement dans SharePoint à partir de Visual Studio. Les sites de développeur Office 365 sont préconfigurés pour l'isolation d'application et pour OAuth : les développeurs peuvent ainsi commencer immédiatement à écrire et à tester des applications.
Les sections suivantes décrivent en détail à quel moment les développeurs peuvent utiliser les différentes options d'environnement pour créer des applications.
Sites de développement Office 365 (cloud public)
La figure 2 montre comment les développeurs peuvent utiliser Office 365 en tant qu'environnement de développement et présente les types d'outil utilisables pour créer des applications SharePoint pouvant être hébergées dans Office 365.
Figure 2. développement d’applications Office 365
[
Les développeurs détenant un abonnement MSDN peuvent obtenir un client de développement contenant un site du développeur SharePoint. Le Site du développeurSharePoint est préconfiguré pour le développement d'applications. Les utilisateurs peuvent non seulement utiliser Visual Studio 2012 pour développer des applications, mais, avec les sites de développeur Office 365, les Outils de développement Office 365 « Napa » peuvent être utilisés au sein du site pour créer des applications. Pour plus d'informations sur la prise en main d'un site du développeur Office 365, consultez Configurer un environnement de développement pour les compléments pour SharePoint dans Office 365.
Les développeurs peuvent commencer à créer des applications hébergées dans Office 365, sur site ou sur une autre infrastructure d'un modèle hébergé par un fournisseur. L'avantage de cet environnement est que l'infrastructure, la virtualisation et d'autres considérations relatives à l'hébergement pour un environnement de développement SharePoint sont abstraites par Office 365, ce qui permet aux développeurs de créer des applications instantanément. Point important concernant ce type d'environnement de développement : les applications qui nécessitent le déploiement d'un code de confiance totale dans SharePoint ne sont pas prises en charge. Microsoft recommande d'utiliser autant que possible le modèle objet client (CSOM) et les technologies côté client SharePoint comme JavaScript. Dans le cas où du code de confiance totale serait nécessaire (mais où le déploiement du code à exécuter sur SharePoint ne serait pas requis), nous vous recommandons de déployer le code côté serveur dans un modèle auto-hébergé ou hébergé par un fournisseur. Notez que ces solutions de code de confiance totale qui sont déployées dans une infrastructure hébergée par un fournisseur utilisent également le modèle CSOM, mais peuvent utiliser des langages tels que C#. Il est également important de noter que les applications déployées dans un modèle hébergé par un fournisseur peuvent employer d'autres piles de technologies tout en continuant à utiliser le modèle CSOM pour interagir avec SharePoint.
Les équipes de développement qui créent des fonctionnalités ou des applications distinctes faisant partie d'une solution plus globale ont besoin d'une cible de déploiement centralisée pour les composants de test d'intégration. Étant donné que chaque développeur crée des fonctionnalités ou applications sur son propre site de développeur Office 365, une collection de sites centralisée doit être configurée sur un client cible ou dans un environnement local afin que les composants d'application de chaque développeur puissent y être déployés. Cette approche offre un emplacement centralisé pour effectuer des tests d'intégration entre les composants de la solution. La section test de ce document examine ce processus plus en détail.
Sites de développement (développement à distance)
Les organisations ou développeurs qui choisissent de ne pas utiliser les sites de développeur Office 365 comme moyen principal de développement d'applications SharePoint peuvent employer les sites de développeur locaux pour développer des applications SharePoint. Dans ce modèle, les fonctionnalités des sites de développeur Office 365 sont remplacées par celles des sites de développeur locaux hébergés dans une batterie de serveurs SharePoint. Les clients peuvent créer un cloud de développement privé en déployant une batterie de serveurs SharePoint destinée à héberger les instances de site de développeur. Ils peuvent fournir leur propre automatisation de gouvernance afin d'assurer la création de modèles de site de développeur ou utiliser les capacités SharePoint propres au produit pour configurer des instances de site de développeur. La figure 3 illustre cette configuration.
Figure 3. Développement d’applications locales avec le modèle de site du développeur
[
La figure 3 décrit les outils de développement et types d'application qui peuvent être activés avec les sites de développeur en cas d'utilisation d'une batterie de serveurs SharePoint en tant qu'hôte. Notez que les Outils de développement Office 365 « Napa »Office 365 ne peuvent pas être utilisés dans cet environnement car il s'agit d'une fonctionnalité seulement offerte avec les sites de développement Office 365.
La batterie de serveurs SharePoint qui héberge les instances de Site du développeur doit être surveillée et répondre aux objectifs de service, de point de récupération et de niveau de temps afin que les développeurs qui y ont recours pour créer des applications puissent être efficaces et ne pas subir de panne. Les clients peuvent appliquer des concepts de cloud privé tels que l'élasticité, des unités d'échelle et une structure de gestion à l'environnement. Les opérations et la gestion doivent être appliquées à la batterie de serveurs SharePoint qui héberge également les sites de développeur. Il est ainsi plus facile d'éviter une multiplication incontrôlée de sites de développeur périmés ou inutilisés et de comprendre à quel moment un dimensionnement de l'environnement est nécessaire.
Les clients peuvent décider d'utiliser des fonctionnalités IaaS (infrastructure as a service) comme Microsoft Azure pour héberger les batteries de serveurs SharePoint qui contiennent et hébergent les sites de développeur, ou leurs propres environnements locaux virtuels ou physiques. Notez que l'utilisation de ce modèle ne nécessite pas d'installer SharePoint pour chaque développeur. Le développement d'applications à distance requiert uniquement que des outils de développement Visual Studio, Office et SharePoint soient installés sur la station de travail du développeur.
Les développeurs doivent établir une infrastructure hébergée par un fournisseur pour déployer les applications hébergées par le fournisseur. Bien que les composants hébergés par un fournisseur d’une application SharePoint puissent être implémentés dans un large éventail de technologies, les développeurs doivent fournir une infrastructure pour héberger ces composants de l’application qui s’exécutent en dehors de SharePoint. Par exemple, si une équipe développe une application SharePoint dont l’expérience utilisateur et d’autres composants résident dans anASP.NET application, l’équipe de développement doit utiliser des versions locales d’IIS,SQL Server, et ainsi de suite s’engager dans des modèles de développement d’équipe ALM traditionnels pour ASP.NET.
Environnements de batterie de serveurs autonomes (développement d’une batterie virtualisée)
Pour les solutions qui nécessitent le déploiement d'un code de confiance totale à exécuter dans une batterie de serveurs SharePoint, la mise en œuvre complète (souvent virtualisée) de SharePoint est nécessaire. Pour obtenir des conseils sur la création d’un environnement de développement local pour SharePoint, voir Configurer un environnement de développement local pour les compléments SharePoint.
La figure 4 montre les types d'application qui peuvent être créés en utilisant un environnement virtualisé local.
Figure 4. Développement local avec un environnement virtuel
[
Les développeurs peuvent mener le développement à distance des applications SharePoint et hébergées sur le cloud au sein de leurs propres batteries de serveurs SharePoint, ainsi que celui des solutions de batterie de serveurs de confiance totale. Ces batteries de serveurs sont souvent hébergées sur un serveur de virtualisation exécuté sur la station de travail du développeur ou dans un cloud privé de virtualisation centralisé facilement accessible aux développeurs. L'environnement de batterie de serveurs SharePoint est généralement séparé des batteries de serveurs des autres développeurs et offre le niveau d'isolation nécessaire pour développer du code de confiance totale pouvant nécessiter le redémarrage de services essentiels (à savoir IIS).
Le développement à distance, ainsi que le développement de code de confiance totale, peut avoir lieu dans la batterie de serveurs autonome car chaque batterie de serveurs de développement est isolée et dédiée à un seul développeur.
Les organisations ou les développeurs doivent gérer et mettre à jour les batteries de serveurs SharePoint exécutées sur les ordinateurs virtuels. Pour les développeurs qui contribuent à une seule application, la parité entre les batteries de serveurs de développement exécutées sur les ordinateurs virtuels doit être maintenue. Cette pratique garantit que chaque composant de code développé pour l'application est cohérent. D'autres considérations communes sont une configuration standard pour les batteries de serveurs, y compris l'accès au domaine et les informations d'identification, les informations d'identification des applications de service, le test des identités ou des comptes, et d'autres éléments de configuration environnementale (tels que les certificats).
À l'instar d'une batterie de serveurs centralisée pour sites de développement, les ordinateurs virtuels exécutant des batteries de serveurs de développeur SharePoint peuvent être hébergés sur des plateformes IaaS telles que Microsoft Azure et les offres de cloud privé sur site.
Notez que, bien que les ordinateurs virtuels offrent un degré non négligeable d'isolation et d'indépendance vis-à-vis des autres ordinateurs virtuels de développeur, les équipes doivent s'efforcer de maintenir une uniformité entre les configurations des ordinateurs virtuels. Cela comprend le recours à un domaine, une sécurité et un compte communs, à des configurations SharePoint et à une connexion à un référentiel de contrôle de code source tel que TFS (Team Foundation Server) Visual Studio.
Considérations en matière de conception ALM
Lors de l'élaboration d'applications SharePoint, il existe plusieurs considérations à prendre en compte pour fournir des pratiques de gouvernance et de développement commun à des fins de cohérence et de qualité. Lors de l'application des principes ALM au développement d'applications SharePoint, les développeurs doivent se concentrer sur les aspects techniques, ainsi que sur les considérations liées au processus.
La prise en charge d'une plateforme ALM, comme Visual Studio Team Foundation Server 2012, est généralement exigée pour développer des applications, notamment avec des équipes de développeurs travaillant sur le même ensemble de projets. Comme d'autres solutions techniques, les applications SharePoint nécessitent la gestion et le contrôle de version du référentiel de code, des services de build, des services de test et des pratiques de gestion des versions. La section suivante décrit les considérations ALM appliquées aux différents modèles d'application SharePoint.
Vue d’ensemble
Pour chaque type d'application SharePoint, les considérations ALM doivent être appliquées sans modification de concept. Cependant, les pratiques et les procédures relatives au build, aux tests et à la gestion des changements doivent être adaptées.
Certaines applications SharePoint utilisent des technologies côté client. La plupart des développeurs qui disposent d'une certaine expérience en développement d'applications SharePoint Server 2010 doivent s'adapter pour développer et appliquer des principes ALM à du code non compilé. Cette adaptation comprend l'application de concepts tels que celui de « build » à une solution pouvant ne pas comporter de code compilé. Les plateformes ALM telles que Visual Studio 2012 intègrent des fonctionnalités permettant de valider des builds en compilant tout d'abord le code, puis en exécutant des tests de vérification de build (BVT).
Pour les applications SharePoint, le processus relatif au build et aux tests doit rester cohérent avec les processus de développement d'applications traditionnels. Cela inclut la création d'une planification de build par la plateforme ALM, chargée de compiler la solution et de la déployer dans l'environnement cible.
Processus de création
Les processus de génération d'applications SharePoint sont facilités par la plateforme ALM. Visual Studio Team Foundation Server 2012 fournit des services de build et de test pouvant être déclenchés lors de l'archivage de la solution à partir de Visual Studio 2012 (intégration continue) ou aux intervalles indiqués.
Composants de SharePoint Build
Lorsqu'ils planifient des processus de génération pour développer des applications SharePoint, les développeurs doivent prendre en compte les interactions entre les composants, comme le montre la figure 5.
Figure 5. Composants de build d’application hébergés par SharePoint
La figure 5 est une représentation logique d'une application SharePoint. Elle montre une Application hébergée par SharePoint et met en évidence des objets d'application clés dans le cadre d'un projet d'Application hébergée par SharePointVisual Studio 2012. Le projet d'application SharePoint contient les caractéristiques, le package et le manifeste à inscrire auprès de SharePoint. Il inclut également des pages, des bibliothèques de scripts et d'autres éléments de l'expérience utilisateur qui constituent l'application SharePoint. En outre, le projet SharePoint comporte des fichiers de prise en charge qui incluent les certificats nécessaires pour le déploiement vers un environnement SharePoint cible.
Figure 6. Composants de build d’application hébergés par un fournisseur et auto-hébergés
La figure 6 montre une application SharePoint hébergée sur le cloud (c'est-à-dire auto-hébergée ou hébergée par un fournisseur). La principale différence au niveau de la structure du projet est que la solution Visual Studio 2012 contient un projet d'application SharePoint en plus d'un ou de plusieurs projets contenant les composants de l'application hébergée sur le cloud. Il peut s'agir d'applications web, de projets de base de données SQL ou d'applications de service à déployer vers Azure ou une infrastructure hébergée par un fournisseur sur site (comme ASP.NET), ainsi que d'autres composants de solution. Pour obtenir des conseils sur l’empaquetage et le déploiement avec des applications à haut niveau de fiabilité, voir Empaqueter et publier des compléments SharePoint à haut niveau de fiabilité.
Figure 7. ALM avec Visual Studio Team Foundation Server
La figure 7 montre TFS en tant que plateforme ALM. Les équipes utilisent TFS déployé sur site ou des services TFS Microsoft basés sur le cloud pour stocker le code et mener à bien le développement en équipe. TFS peut être configuré pour effectuer des activités de build et de déploiement sur une application SharePoint, via des définitions de build. Il peut également servir à effectuer des tests de vérification de build (BVT) automatisables via l'exécution de tests d'interface utilisateur codés faisant partie de la définition de build.
Figure 8. Cibles de build TFS
La figure 8 montre les environnements cibles où les scripts exécutés par une définition de build TFS déploient les composants d'application SharePoint. Pour les applications hébergées sur SharePoint, ceci inclut le déploiement vers SharePoint Online ou vers des catalogues d'applications SharePoint sur site.
Pour les applications SharePoint hébergées sur le cloud, les composants de la solution nécessitant une infrastructure supplémentaire en dehors de SharePoint sont déployés vers des environnements cibles. Pour les applications auto-hébergées, il s'agit de Microsoft Azure. Pour les applications hébergées par un fournisseur, cette infrastructure peut être Microsoft Azure ou un autre environnement hébergé sur IaaS ou sur site.
Création d’un build pour les applications SharePoint
TFS fournit des services de build à même de compiler les solutions vérifiées dans un contrôle de code source et de placer la sortie dans un emplacement cible centralisé en vue d'un déploiement automatisé vers des environnements cibles. La principale méthode de configuration de TFS pour mener des builds, des déploiements et des tests automatisés d'applications SharePoint consiste à créer une définition de build dans Visual Studio. Cette définition contient des informations sur les projets de code à compiler, ainsi que les activités de post-compilation telles que les tests et le déploiement réel vers les environnements cibles. Pour plus d’informations sur team Foundation Build Service, consultez Configurer Team Foundation Build Service.
Pour réaliser une intégration continue, la définition de build peut être déclenchée lorsque les développeurs archivent le code. Elle peut aussi être programmée pour s'exécuter selon des intervalles indiqués.
Pour les applications SharePoint, les développeurs doivent utiliser le projet d’intégration continue Office/SharePoint avec les définitions de build TFS 2012 pour obtenir des builds planifiées ou une intégration continue. Ce projet fournit des définitions de build, des scripts Windows PowerShell et des instructions de processus sur la façon de configurer Visual Studio Team Services ou une version sur site de TFS pour créer et déployer des applications SharePoint dans un modèle d'intégration continue. Les développeurs doivent télécharger les composants de ce projet et configurer leur instance de TFS en conséquence. Pour obtenir des instructions sur la façon de configurer TFS avec la définition de build fournie pour les applications SharePoint et de configurer la définition de build de manière à utiliser les scripts Windows PowerShell afin de déployer l'application SharePoint vers un environnement cible, voir la documentation relative à l'intégration continue Office/SharePoint avec TFS 2012.
Configuration des procédures de build et de déploiement
La figure 9 montre un processus standard de build et de déploiement d'applications SharePoint une fois la définition de build créée, configurée et déployée vers l'instance TFS de l'équipe.
Figure 9. Processus de génération et de déploiement avec TFS
[Les 
Le développeur archive la solution Visual Studio 2012 d'application SharePoint. Selon la configuration souhaitée (intégration continue ou build planifié), les services de build TFS exécutent les étapes définies dans la définition de build d'application SharePoint. Configurée par les développeurs, cette définition contient le modèle de processus de génération d'intégration continue ainsi que des instructions après build relatives à l'exécution de scripts Windows PowerShell pour déployer des applications. Notez que les extensions SharePoint Online Management Shell sont nécessaires pour déployer l'application vers SharePoint Online. Pour plus d’informations sur les extensions SharePoint Online Management Shell, consultez la page SharePoint Online Management Shell dans le Centre de téléchargement.
Une fois le build déclenché, TFS compile les projets associés à l'application SharePoint et exécute des scripts Windows PowerShell pour déployer la solution vers l'environnement SharePoint cible.
Approbation de l’application SharePoint
Une fois les composants de l'application déployés vers les environnements cibles, il est important de noter que, avant tout accès à l'application, y compris pour d'éventuels tests automatisés intégrés au build, un administrateur de client (ou de collection de sites) doit approuver l'application dans la page d'informations correspondante dans SharePoint. Cette exigence s'applique aux applications auto-hébergées et hébergées sur SharePoint. Ce processus manuel représente une évolution au niveau du processus de génération : les tests normalement effectués après le déploiement vers l'environnement cible sont mis en suspens jusqu'à approbation de l'application.
Notez que pour les applications hébergées sur le cloud (auto-hébergement ou hébergement par un fournisseur), les développeurs peuvent déployer les composants autres que SharePoint vers l'infrastructure hébergée sur le cloud séparément du package d'application, qui est déployé vers SharePoint.
Figure 10. Déploiement de composants non SharePoint
[
Comme le montre la figure 10, lorsque des développeurs modifient la solution que représente l'application SharePoint, il existe des cas où les modifications apportées aux projets au sein de la solution ne s'appliquent pas au projet d'application SharePoint en lui-même. Dans ce cas, le projet d'application SharePoint n'a pas besoin d'être redéployé puisqu'il n'a pas changé. Les modifications associées aux projets hébergés sur le cloud doivent être redéployées.
Les modifications apportées à l'application à déployer vers une infrastructure extérieure à SharePoint peuvent être effectuées distinctement de celles concernant les composants d'application déployés vers le client ou la collection de sites cible. Pour les développeurs, cela signifie qu'un processus de génération automatisé peut être mis au point pour déployer de manière régulière (déclenchée) les composants hébergés sur le cloud, séparément du projet d'application SharePoint. L'étape manuelle d'approbation de l'autorisation de l'application dans la page d'informations de l'application dans SharePoint n'est ainsi pas nécessaire, ce qui donne lieu à un processus de déploiement et de test plus continu pour la définition du build. Le composant d'application SharePoint de la solution ne doit être déployé que si les éléments du projet ont changé et qu'un redéploiement est requis.
Tests
Comme décrit dans la section Processus de génération, le test d’application est une méthode permettant de déterminer si la compilation et le déploiement de l’application ont réussi. En utilisant les tests pour vérifier le build et le déploiement de l'application, l'équipe est en mesure de vérifier la qualité, ainsi que de savoir si un changement récent apporté au code de l'application a compromis l'application SharePoint.
La figure 11 montre les types d'approche de test les plus adaptés aux modèles d'application SharePoint.
Figure 11. Approches de test
[
La figure 11 suggère l'utilisation de différents types de test en fonction du type d'application SharePoint. Les tests codés de l'interface utilisateur doivent être effectués sur les applications hébergées par SharePoint où la logique métier et l'expérience utilisateur résident dans la même couche. Si la logique métier peut être abstraite dans des bibliothèques JavaScript, un des principaux moyens de tester cette logique est l'expérience utilisateur.
Les applications hébergées sur le cloud (auto-hébergées ou hébergées par un fournisseur) peuvent utiliser des tests entièrement codés de l'interface utilisateur tout en employant des tests unitaires pour vérifier les composants de service de la solution. Le développeur a ainsi confiance en la qualité de la mise en œuvre de l'infrastructure hébergée de l'application d'un point de vue fonctionnel.
Les sections suivantes passent en revue des considérations relatives aux tests codés de l'interface utilisateur et à d'autres types de test en rapport avec les applications SharePoint.
Code côté client et tests codés de l’interface utilisateur
Pour les tests de vérification de build (BVT) ainsi que pour les tests du système complet, des tests codés de l'interface sont recommandés. Ces tests reposent sur des actions enregistrées qui visent à tester non seulement la logique métier et le niveau intermédiaire de l'application, mais aussi l'expérience utilisateur. Pour les applications SharePoint qui utilisent du code côté client, une grande partie de l'exécution et des points d'entrée de la logique métier peut exister dans le niveau de l'expérience utilisateur. Pour cette raison, les tests codés de l'interface utilisateur peuvent non seulement tester l'expérience utilisateur, mais aussi la logique métier de l'application. Pour plus d’informations sur le test codé de l’interface utilisateur, consultez Vérification du code à l’aide de UI Automation.
Les tests codés de l'interface utilisateur peuvent être employés dans toute Application hébergée par SharePoint, où l'interface utilisateur et la logique métier peuvent être en grande partie entremêlées. Comme d'autres, ces tests peuvent être exécutés à partir d'une définition de build dans TFS de façon à vérifier les fonctionnalités d'une application après son déploiement (et son approbation par SharePoint).
Tests d’interface utilisateur non codés
Pour les cas où la logique de l'application existe en dehors de la couche d'expérience utilisateur de l'application, comme dans les applications hébergées sur le cloud, une combinaison de tests codés et non codés de l'interface utilisateur doit être effectuée. Des tests tels que les tests unitaires traditionnels peuvent être employés pour valider la qualité de build de la logique de service mise en œuvre sur une infrastructure hébergée par un fournisseur. Le développeur a ainsi une confiance globale dans les composants hébergés par un fournisseur de la fonction de solution et est couvert du point de vue des tests.
Tests de performances et de chargement web
Grâce aux tests de performance web et de charge, les développeurs savent si les fonctions d'application sous-estiment ou anticipent les charges utilisateur. Ces tests consistent notamment à déterminer la capacité de l'application à gérer une base d'utilisateurs prévisible susceptible de connaître un certain développement au fil du temps. Les tests codés de l'interface utilisateur et les tests unitaires peuvent servir de base aux tests de performance web et de charge. Dans une plateforme ALM comme TFS, ils peuvent être utilisés pour effectuer les tests de charge de l'application.
Notez que tester l'infrastructure n'est pas l'objectif premier de ces tests lors de leur utilisation avec les applications SharePoint. Une même ligne de base de performances et de charge doit être établie pour l'infrastructure, que cette dernière soit hébergée sur SharePoint ou sur un fournisseur. Les tests de performance web et de charge de l'application mettent en évidence les défis que doit relever l'infrastructure, mais doivent surtout être considérés comme un moyen de tester les performances de l'application.
Pour plus d’informations sur les tests de performances web et de charge, consultez Exécuter des tests de performances sur une application avant une mise en production.
Environnements de qualité et de test
De nombreuses organisations ont plusieurs environnements de test qui peuvent être physiques ou virtuels et séparés les uns des autres. Ces environnements peuvent varier en fonction du processus ALM d’une équipe, des exigences réglementaires ou d’une combinaison des deux. Pour déterminer le nombre et les types d’environnements de test que les équipes doivent utiliser, les conseils suivants sont basés sur des pratiques fonctionnelles spécifiques aux applications SharePoint, mais utilisent également des pratiques ALM pour le développement logiciel en général.
Tests pour les développeurs
Le testing des développeurs peut être effectué dans l'environnement dans lequel les développeurs créent leur composant de la solution. Plusieurs développeurs, travaillant sur différents aspects ou composants d'une application plus globale, disposent chacun de tests unitaires, de tests codés de l'interface utilisateur et du code d'application déployé sur leur site de développement.
Figure 12. Processus de test des développeurs
[
Les développeurs exécuteront des tests à partir de Visual Studio sur les composants de solution déployés dans leur propre site Office 365 ou de développeur sur site. Pour les applications hébergées sur le cloud, les tests sont également exécutés à partir de Visual Studio sur les composants de solution résidant dans une infrastructure hébergée sur un fournisseur. Ces composants résident dans l'abonnement Microsoft Azure du développeur.
Notez que cette approche suppose que les développeurs disposent de sites de développeur Office 365 individuels et d'abonnements Microsoft Azure, fournis par le biais d'abonnements MSDN. Même si les développeurs créent des applications pour un déploiement sur site, ces services de développeur peuvent être utilisés pour le développement et les tests.
Si les développeurs ne disposent pas de ces services, ou doivent effectuer le développement entièrement sur site, ils testent leurs composants dans la collection de sites de développeur d'une batterie de serveurs sur site et dans une infrastructure hébergée par un fournisseur propre aux développeurs. L'infrastructure hébergée par un fournisseur peut résider sur des ordinateurs virtuels dédiés aux développeurs. Pour le développement de solutions de confiance totale, les développeurs ont besoin de leur propre batterie de serveurs SharePoint virtuelle et d'une infrastructure hébergée par un fournisseur.
Tests d’intégration et de système
Pour tester l'application, tous les composants de développement doivent être assemblés et déployés dans un environnement centralisé. Dans cet environnement d'intégration, les développeurs peuvent déployer les composants de la solution créée et observer leur interaction avec d'autres composants de solution écrits par d'autres développeurs.
Figure 13. Environnement de test d’intégration
[
Pour ce type de test, la plateforme ALM crée et déploie l’application SharePoint et tous les composants obligatoires sur les environnements cibles. Pour les applications hébergées sur SharePoint, il s'agit d'une collection de sites SharePoint sur site/IaaS ou d'un site Office 365 spécifiquement mis en place pour les tests d'intégration et de systèmes. Pour les applications hébergées sur le cloud SharePoint, TFS déploie également les composants vers un abonnement Microsoft Azure centralisé où les services sont spécifiquement configurés pour les tests d'intégration/de systèmes. TFS exécute alors des tests codés d'interface utilisateur ou des tests unitaires sur l'application SharePoint, ainsi que sur tout composant requis par la solution dans l'infrastructure hébergée.
Tests UAT et QA
Les organisations disposent souvent d'environnements distincts où les tests d'acceptation utilisateur (UAT) sont effectués à part par rapport aux tests d'intégration et de systèmes. La séparation de ces environnements de test empêche la cadence des publications et tests continus automatisés d'interférer avec les activités UAT, au cours desquelles les utilisateurs sont susceptibles d'effectuer des tests sur un build donné de l'application sur une longue période.
Figure 14. Test UAT
[
Comme le montre la figure 14, les utilisateurs désignés pour effectuer des tests d'acceptation ou d'organisation sur des ressources exécutent des scripts de test dans un environnement stable qui se concentre sur un build bien connu de l'application. Alors que le déploiement de code et les tests se poursuivent dans l'environnement d'intégration, les utilisateurs effectuent des tests manuels pour vérifier que l'application répond à l'utilisation prévue ou aux cas de test. L'application et toute infrastructure hébergée par un fournisseur sont déployées, généralement par un responsable de la livraison, dans l'environnement de test. Un déploiement automatisé est aussi possible. Ce type de déploiement utilise une définition de build d'UAT dédiée dans TFS, qui reflète celle effectuant le déploiement pour l'environnement de test d'intégration et de systèmes.
Pour l'infrastructure hébergée sur le cloud, le déploiement dans un abonnement Microsoft Azure partagé avec les environnements de test d'intégration et de systèmes est possible si les services sont nommés et configurés pour être déployés côte à côte en tant que différents services ou bases de données. Cette approche fournit un ensemble de services et de bases de données dans l'abonnement Microsoft Azure de test en vue des tests d'intégration et de systèmes, ainsi que des tests d'acceptation utilisateur et d'assurance qualité, comme le montre la figure 15.
Figure 15. Intégration et tests UAT
[
Pratiques de promotion du code
Le processus de promotion du code entre les environnements de développement et de test, ainsi que l'environnement de production, doit être effectué selon un processus de gestion des versions bien défini. Sur la figure 16, les développeurs déploient leurs composants de solution vers des environnements de développement en vue des tests unitaires.
Figure 16. Processus de gestion des mises en production
[
Après l'archivage vers TFS, une procédure de build automatisée compile et déploie la solution dans l'environnement de test d'intégration et de systèmes cible où des tests de vérification de build sont exécutés dans le cadre de la définition de build dans TFS. Cette approche inclut le déploiement des composants de la solution hébergés par un fournisseur vers l'environnement cible (Microsoft Azure ou sur site). Notez que pour l'infrastructure Microsoft Azure, l'abonnement Microsoft Azure peut être le même que celui utilisé pour les tests d'intégration et de systèmes, ainsi que pour les tests d'acceptation utilisateur et d'assurance qualité, à condition que le déploiement ait lieu vers différents espaces de noms et des bases de données SQL distinctes.
Un responsable de la livraison ou une définition de build TFS distincte, appelée manuellement dans la plupart des cas, peut effectuer un déploiement vers l'environnement de test d'acceptation utilisateur (UAT) ou d'assurance qualité. Cette approche permet de contrôler la version de build testée par les utilisateurs. Les responsables de livraison peuvent récupérer les builds dans un partage TFS et exécuter eux-mêmes le processus de déploiement. De la promotion à la production, la gestion des versions est impliquée pour déployer l'application dans l'environnement de production et surveiller son installation et la vérification du build par des tests.
Correctifs et mises à niveau des applications
Microsoft propose des conseils spécifiques sur la façon dont les développeurs d'applications peuvent mettre à niveau des applications. La plateforme SharePoint prend en charge la notification des nouvelles versions d'application aux utilisateurs.
Pour plus d’informations sur l’établissement d’une stratégie concernant les mises à niveau et les mises à jour correctives des applications SharePoint, voir Mettre à jour les compléments SharePoint.
Pour les modifications des applications, le modèle qu'il est recommandé de suivre est cohérent par rapport aux modèles de développement de code et d'ingénierie après publication existants. Cela comprend la création de branche et la fusion méthodiques pour les résolutions de bogue et le développement de fonctionnalités, ainsi que des déploiements incrémentiels vers des catalogues d'applications cibles. Les instructions précédentes peuvent être utilisées afin d'apporter des modifications aux applications pour SharePoint et de déployer ces dernières vers des catalogues d'applications cibles ou le magasin.
Les informations contenues dans le processus de mise à jour des compléments SharePoint fournissent des conseils tactiques supplémentaires sur les techniques de mise à jour des applications SharePoint. Il s'agit par exemple d'accélérer les tests de déploiement en raccourcissant le cycle de prise en compte des mises à jour d'application dans la batterie de serveurs dans les environnements de test. En outre, cet article explique comment s'adapter à l'état dans divers modèles de déploiement des applications.