Développement en équipe sur SharePoint Framework

SharePoint Framework est un nouveau modèle de développement pour la création des personnalisations de SharePoint. Contrairement à d’autres modèles de développement SharePoint disponibles à ce jour, SharePoint Framework se concentre sur le développement côté client et est basé sur des outils open source très populaires tels que gulp et webpack. L’un des grands avantages de ce changement est que les développeurs sur n’importe quelle plate-forme peuvent créer des personnalisations de SharePoint.

SharePoint Framework est un modèle de développement et, malgré les différences dans la technologie sous-jacente, les mêmes concepts s’appliquent lors de son utilisation pour créer des solutions que pour d’autres modèles de développement utilisés par les développeurs SharePoint par le passé. Les développeurs utilisent la chaîne d’outils SharePoint Framework pour créer et tester leurs solutions et, une fois prêts, ils passent le package de solution à déployer sur le locataire SharePoint pour des tests et une publication ultérieurs.

L’infrastructure SharePoint est composée de plusieurs packages différents. Ces packages, chacun dans sa propre version, constituent une version de l’infrastructure SharePoint. Par exemple, la version de disponibilité générale de SharePoint Framework en février 2017 se compose des versions de package v1.0.0 suivantes :

  • @microsoft/sp-client-base
  • @microsoft/sp-core-library
  • @microsoft/sp-webpart-base
  • @microsoft/sp-build-web
  • @microsoft/sp-module-interfaces
  • @microsoft/sp-webpart-workbench

Pour qu’un projet cible une version spécifique de SharePoint Framework, il doit référencer tous les différents packages dans les versions correctes. Lors de la génération automatique de nouveaux projets, le générateur Yeoman sharePoint Framework ajoute automatiquement les références nécessaires au package à partir de la version correspondante de SharePoint Framework. Toutefois, lors de la mise à niveau du projet vers une version plus récente de SharePoint Framework, les développeurs doivent prêter une attention particulière pour mettre à jour correctement les numéros de version des packages SharePoint Framework.

Préparation de l’environnement de développement

Pour créer des solutions SharePoint Framework, les développeurs ont besoin d’outils spécifiques sur les ordinateurs de développement. Comparée à d’autres modèles de développement de SharePoint, SharePoint Framework est moins restrictif et permet aux développeurs d’utiliser les outils qui leur permettent d’être les plus productifs, allant même jusqu’à choisir le système d’exploitation.

Il existe différentes manières pour les développeurs de configurer leur environnement de développement. Chacune d’elles présente des avantages différents, et il est important que les équipes de développeurs comprennent bien les différentes options.

Chaîne d’outils de SharePoint Framework

Pour créer des solutions SharePoint Framework, les développeurs doivent utiliser un certain ensemble d’outils. La liste suivante présente l’ensemble d’outils de base nécessaires sur chaque environnement de développement de SharePoint Framework.

Node.js

SharePoint Framework exige que Node.js soit installé sur l’ordinateur du développeur. Node.js est utilisé comme le runtime pour les outils de conception utilisés pour créer et préparer le projet. Node.js est installé globalement sur l’ordinateur du développeur et il existe des solutions disponibles pour prendre en charge l’exécution de plusieurs versions de Node.js côte-à-côte si nécessaire.

Pour plus d’informations, consultez Configuration de votre environnement de développement SharePoint Framework

NPM

Npm est l’équivalent de NuGet dans les projets .NET : il permet aux développeurs d’acquérir et d’installer des packages pour les utiliser dans les projets SharePoint Framework. Npm est également utilisé pour installer la chaîne d’outils de l’infrastructure SharePoint. En règle générale, les développeurs utilisent la dernière version de npm et l’installe globalement sur leur ordinateur. Npm lui-même est un package de Node.js. Par conséquent, si vous exécutez plusieurs versions de Node.js côte-à-côte, chacune aura sa propre version de npm installée.

Gulp

Gulp est l’équivalent de MSBuild dans les projets .NET et est responsable de l’exécution de tâches telles que la création ou la préparation d’un projet SharePoint Framework. Gulp est distribué sous forme de package Node.js et est généralement installé globalement à l’aide de npm.

Yeoman et générateur Yeoman pour SharePoint Framework

À l’aide de Yeoman et du générateur Yeoman pour SharePoint Framework, créez des projets SharePoint Framework. Yeoman et ses générateurs sont distribués sous forme de packages Node.js et sont généralement installés à l’aide de npm sous forme de packages globaux. L’avantage d’une installation globale est que les développeurs peuvent installer Yeoman et les générateurs une seule fois et les utiliser pour créer facilement des projets.

Le générateur Yeoman de SharePoint Framework est lié à une version spécifique de SharePoint Framework. Les projets dont la structure a été créée à l’aide du générateur font référence aux versions spécifiques des packages SharePoint Framework et les composants WebPart générés font référence aux éléments spécifiques de l’infrastructure. Le générateur Yeoman de SharePoint Framework est utilisé pour créer des projets, mais aussi pour ajouter des composants WebPart dans des projets existants. Si vous l’installez globalement et que vous devez ajouter un nouveau composant WebPart à un projet existant créé dans le passé, le composant WebPart nouvellement créé risque d’être incohérent avec le reste du projet, ce qui peut même entraîner des erreurs de build. Vous pouvez contourner cette restriction de différentes façons, comme décrit dans cet article ultérieurement.

TypeScript

SharePoint Framework utilise TypeScript pour aider les développeurs à être plus productifs en écrivant un meilleur code et en détectant les erreurs dès le développement. Les projets SharePoint Framework sont fournis avec leur propre version de TypeScript qui est utilisée dans le processus de création et qui n’exige pas que les développeurs l’installent séparément.

Création d’un environnement de développement SharePoint Framework

Dans le passé, les développeurs SharePoint utilisaient généralement des machines virtuelles comme environnements de développement. Les machines virtuelles leur permettaient de s’assurer que la solution qu’ils créaient était compatible avec l’environnement utilisé par cette organisation. Dans leurs machines virtuelles, les développeurs installaient SharePoint et les mêmes niveaux de correctifs que l’environnement de production utilisé par l’organisation en question. Dans certains cas, ils installaient un logiciel supplémentaire adapté à l’environnement cible où la solution était exécutée aussi minutieusement que possible. Cette approche a permis aux développeurs de détecter plus tôt les erreurs causées par la différence d’environnements au prix d’une grande complexité et en gérant les différents environnements.

Le passage au développement de solutions pour le cloud a résolu ces problèmes de façon partielle uniquement. Les développeurs ne devaient plus exécuter une batterie de serveurs SharePoint sur leurs ordinateurs de développement, mais ils devaient analyser comment leur solution serait hébergée et comment elle communiquerait avec SharePoint Online.

Comme SharePoint Framework se concentre sur le développement côté client, SharePoint ne doit plus être installé sur les ordinateurs de développement. À quelques exceptions près, toutes les dépendances de l’infrastructure et les autres packages sont spécifiés dans le projet et contenus dans le dossier du projet. Comme SharePoint Framework a ses origines dans le cloud et évolue souvent, les développeurs doivent s’assurer qu’ils utilisent la version correcte de la chaîne d’outils correspondant à leur projet SharePoint Framework.

Environnement de développement personnel ou partagé

Les personnalisations de SharePoint englobent aussi bien les scripts simples ajoutés directement à la page que les solutions sophistiquées déployées en tant que packages de solutions. SharePoint Framework est un modèle de développement qui cible le modèle de déploiement structuré et reproductible des personnalisations de SharePoint. Lorsque vous créez des solutions SharePoint Framework, chaque développeur de l’équipe utilise son propre environnement de développement et partage le code source du projet avec d’autres développeurs de l’équipe dans un système de contrôle source. Ainsi, les développeurs peuvent travailler simultanément sur le même projet et tester leur solution sans affecter la productivité des autres.

Dans le passé, il était difficile pour de nombreuses organisations de justifier le fait de fournir des ordinateurs de développement puissants aux développeurs SharePoint et dans certains cas, plusieurs développeurs devaient partager le même ordinateur au détriment de la productivité. Avec SharePoint Framework, les développeurs peuvent utiliser des ordinateurs standard pour créer des personnalisations de SharePoint.

Développement sur l’hôte

L’option probablement la plus simple pour configurer un environnement de développement pour les projets SharePoint Framework consiste à installer tous les outils directement sur l’ordinateur hôte. Si votre équipe travaille uniquement sur des projets SharePoint Framework, ils peuvent installer Node.js sur leurs ordinateurs. S’ils travaillent sur d’autres projets Node.js, ils peuvent utiliser des solutions tierces comme nvm pour exécuter plusieurs versions de Node.js côte-à-côte.

Après les outils requis par la chaîne d’outils pour SharePoint Framework, les développeurs doivent installer Yeoman et le générateur Yeoman pour SharePoint Framework. En règle générale, ces deux outils sont installés globalement. Cependant, comme le générateur Yeoman pour SharePoint Framework est lié à une version spécifique de SharePoint Framework et que les développeurs risquent de devoir travailler avec des projets créés à l’aide d’une version différente, ils devraient désinstaller et installer la version du générateur spécifique du projet sur lequel ils travaillent actuellement. Une approche plus envisageable serait d’installer Yeoman globalement, et le générateur Yeoman pour SharePoint Framework localement dans le projet donné. Cela introduit un peu plus de charge, mais aide les développeurs à s’assurer que s’ils ont besoin d’ajouter de nouveaux éléments au projet à l’avenir, ces derniers seront compatibles avec le reste du projet.

L’un des avantages du développement sur l’hôte est que les développeurs peuvent configurer leur ordinateur selon leurs préférences une seule fois et l’utiliser pour tous les projets. En outre, comme le logiciel est exécuté sur l’hôte, il accède directement au processeur, à la mémoire et aux E/S des disques sans couche de virtualisation entre les deux, ce qui entraîne de meilleures performances que lors de l’exécution du même logiciel virtualisé.

Développement dans une machine virtuelle

Dans le passé, l’approche la plus courante chez les développeurs de SharePoint consistait à utiliser des machines virtuelles comme environnement de développement principal pour créer des solutions SharePoint. À l’aide des machines virtuelles, les développeurs pouvaient répondre aux différentes exigences pour les différents projets.

Lors de la création de solutions sur SharePoint Framework, les organisations peuvent utiliser les mêmes avantages qu’elles utilisaient lors de la création de solutions SharePoint dans le passé. Les machines virtuelles leur permettent d’isoler les logiciels de développement du système d’exploitation hôte - une exigence courante notamment dans les grandes organisations. En créant une machine virtuelle distincte pour chaque projet, les développeurs peuvent garantir que la chaîne d’outils qu’ils utilisent est compatible avec le projet, même s’ils doivent sélectionner le projet en question à l’avenir.

L’utilisation de machines virtuelles n’est pas sans inconvénients. Les machines virtuelles sont volumineuses et exigent que les développeurs utilisent des ordinateurs suffisamment puissants pour les exécuter avec des performances acceptables pour être productifs. En outre, les développeurs doivent maintenir le système d’exploitation à jour et vérifier qu’ils exécutent toutes les mises à jour de sécurité nécessaires, notamment sur de longues périodes. Les développeurs qui travaillent sur une machine virtuelle doivent consacrer du temps au début d’un nouveau projet pour configurer la machine virtuelle standard selon leurs préférences ou accepter la configuration standard, au détriment de leur productivité. Comme les machines virtuelles exécutent un système d’exploitation complet avec tous ses composants, il est beaucoup plus difficile de garantir que toutes les machines virtuelles utilisées par tous les développeurs de l’équipe sont compatibles. Par rapport à d’autres types d’environnements de développement, l’utilisation de machines virtuelles pour créer des solutions SharePoint Framework est coûteuse à la fois en matière de coût et de temps.

Développement à l’aide de Docker

Une solution intermédiaire intéressante entre le développement sur l’hôte et le développement dans une machine virtuelle consiste à utiliser Docker. Docker est une technologie de virtualisation logicielle semblable aux machines virtuelles avec quelques différences. Les principaux avantages de l’utilisation d’images Docker sur des machines virtuelles sont les suivants : les images Docker sont plus faciles à créer, à gérer et à distribuer ; elles sont plus légères (quelques centaines de Mo par rapport aux dizaines de Go d’espace disque requis pour les machines virtuelles) ; et elles permettent aux développeurs d’utiliser les outils et les préférences qu’ils ont déjà installés et configurés sur leur ordinateur hôte.

À l’instar des machines virtuelles, les conteneurs Docker exécutent une instance virtualisée d’un système d’exploitation (généralement basé sur Linux). Tous les logiciels installés dans l’image utilisée pour créer le conteneur sont exécutés de façon isolée à l’intérieur de ce dernier et accèdent uniquement à la partie du système de fichiers hôte explicitement partagé avec le conteneur. Comme toutes les modifications apportées au système de fichiers dans un conteneur Docker sont abandonnées une fois que le conteneur est fermé, les développeurs partagent des dossiers de leur hôte pour stocker le code source.

Pour plus d’informations, consultez utilisation de Docker pour créer des solutions SharePoint Framework.

Flux de travail de développement dans les projets SharePoint Framework

SharePoint Framework est basé sur une chaîne d’outils open source et suit le flux de travail de développement général présent dans d’autres projets créés sur la même pile. Vous trouverez une description de l’aspect de ce flux de travail dans un projet SharePoint Framework classique.

Création d’un projet SharePoint Framework

Lors de la création des personnalisations de SharePoint à l’aide de l’infrastructure SharePoint, la première étape consiste à créer la structure d’un nouveau projet d’infrastructure SharePoint. Pour cela, utilisez le générateur Yeoman pour infrastructure SharePoint. Le générateur vous invite à répondre à plusieurs questions concernant le nom du projet ou son emplacement. Il vous permet également de créer le premier composant WebPart ou la première extension. Bien que vous soyez libre de choisir une infrastructure JavaScript différente pour chacun de vos composants, la recommandation générale consiste à utiliser une infrastructure unique par projet SharePoint Framework.

Verrouillage de la version des dépendances

Un nouveau projet SharePoint Framework dont la structure est créée par le générateur Yeoman de SharePoint Framework comporte des dépendances avec les packages SharePoint Framework et les autres packages requis pour qu’il s’exécute correctement. À mesure que vous créez vos composants WebPart, vous pouvez inclure des dépendances supplémentaires comme Angular ou jQuery. Dans les projets SharePoint Framework, les dépendances sont installées à l’aide de npm. Chaque dépendance est un package Node.js avec une version spécifique. Par défaut, les dépendances sont référencées à l’aide d’une plage de versions qui permet aux développeurs de maintenir à jour leurs dépendances plus facilement. Une conséquence de cette approche est que la restauration des dépendances pour le même projet à deux moments distincts peut donner des résultats différents et même entraîner l’interruption du projet.

Une solution courante pour éviter le risque de dépendances modifiées au cours du projet (dans les projets créés sur la chaîne d’outils open source) est de verrouiller la version de toutes les dépendances. Lors de l’ajout d’une dépendance au projet, les développeurs peuvent choisir d’installer la dépendance avec une version spécifique au lieu d’une plage de versions en appelant la commande npm installe avec l’argument --save-exact.

Néanmoins, cela n’affecte pas les dépendances enfant du package en question. Pour verrouiller efficacement la version de toutes les dépendances et de leurs enfants dans le projet, les développeurs peuvent utiliser la fonctionnalité de fichier de verrouillage native prise en charge par NPM. Pour plus d’informations, consultez npm-package-locks : Une explication des fichiers de verrouillage NPM.

Ajout du projet au contrôle source

Pour permettre au reste de l’équipe de travailler sur le même projet, ajoutez-le au système de contrôle source utilisé par votre équipe. Les étapes exactes varient en fonction du système utilisé par votre équipe.

La structure des projets SharePoint Framework est créée avec le fichier .gitignore qui décrit les fichiers à exclure du contrôle source. Si votre équipe utilise un système de contrôle source autre que Git (Visual Studio Team System avec référentiels Team Foundation System, par exemple), vous devez vous assurer que vous incluez les fichiers corrects à partir du projet dans le contrôle source. Vous pouvez aussi exclure les dépendances et les fichiers générés automatiquement pendant le processus de création pour vous assurer que votre équipe fonctionnera efficacement.

Les développeurs doivent particulièrement veiller à ne pas inclure le dossier node_modules dans le contrôle source. Ce dossier contient des packages dont dépend le projet et qui sont installés automatiquement lorsque vous restaurez des dépendances à l’aide de la commande npm installe. Certains packages sont compilés dans des fichiers binaires où le processus de compilation dépend du système d’exploitation. Si l’équipe travaille sur différents systèmes d’exploitation et que le dossier node_modules est inclus dans le contrôle source, le build risque d’être interrompu pour certains membres de l’équipe.

Obtention du projet du contrôle source

La première fois que vous obtenez le projet du contrôle source, vous obtenez le code source du projet, mais aucune bibliothèque SharePoint Framework requise pour créer le projet. Comme lorsque vous travaillez avec des projets .NET et utilisez des packages NuGet, vous devez d’abord restaurer les dépendances. Dans les projets SharePoint Framework, à l’instar de tous les autres projets basés sur Node.js, vous devez exécuter npm installe dans la ligne de commande. NPM utilise les informations issues du fichier package.json avec les informations du fichier package-lock.json et installe tous les packages.

Notes

Généralement, la restauration des dépendances à l’aide de la commande npm installe nécessite une connexion Internet, car les packages sont téléchargés à partir de https://registry.npmjs.org.

Si vous rencontrez des problèmes de connectivité réseau ou que le registre NPMJS n’est pas disponible, votre build échoue. Il existe plusieurs façons de contourner cette restriction. L’une d’elles consiste à utiliser shrinkpack pour télécharger les archives de toutes les dépendances et les stocker dans le contrôle source. Shrinkpack met automatiquement à jour le fichier npm-shrinkwrap.json pour utiliser les archives locales permettant l’installation hors ligne des dépendances du projet.

Certains packages sont compilés en fichiers binaires pendant le processus d’installation. Ce processus de compilation est spécifique à l’architecture et au système d’exploitation. Si vous restaurez des dépendances dans un conteneur Docker exécutant Linux et que vous essayez ensuite de générer le projet sur votre hôte Windows, vous obtenez une erreur signalant l’incompatibilité dans le type d’environnement utilisé pour générer et exécuter les fichiers binaires.

Au fur et à mesure que votre équipe développe la solution, vous pouvez ajouter de nouvelles dépendances ou des dépendances mises à jour au projet. Si le fichier package.json a été modifié depuis que vous avez obtenu votre dernier projet du contrôle source, vous devez exécuter npm installe dans la ligne de commande pour installer les dépendances manquantes. Si vous ne savez pas si le fichier package.json a été modifié, vous pouvez exécuter npm installe dans la ligne de commande uniquement pour vous assurer que vous disposez des dernières dépendances, sans altérer le projet.

Ajout de packages au projet

L’utilisation de packages existants pour accomplir des tâches spécifiques vous permet de gagner en productivité. https://www.npmjs.com est un registre public de packages que vous pouvez utiliser dans votre projet.

Important

Dans la mesure où il n’existe aucun processus de vérification formel avant la publication d’un package sur https://www.npmjs.com, vous devez examiner soigneusement si vous pouvez utiliser le package en question d’un point de vue du contenu et de la licence.

Pour ajouter un package à votre projet SharePoint Framework, exécutez la commande npm installe --enregistrer ou npm installe --save-dev dans la ligne de commande, par exemple :Angulaire npm installe --enregistrer. Utilisez l’argument --enregistrer ou --save-dev pour vous assurer que le package est ajouté au fichier package.json et d’autres développeurs de votre équipe l’obtiendront aussi lors de la restauration des dépendances. Sans celui-ci, la création du projet sur un ordinateur différent du vôtre échouera. Lors de l’ajout de packages requis par votre solution au moment de l’exécution (Angular ou jQuery, par exemple), vous devez utiliser l’argument --enregistrer. Les packages requis dans le processus de création, telles que les tâches Gulp supplémentaires, doivent être installés avec l’argument --enregistrer-dev.

Lors de l’installation d’un package, si vous ne spécifiez aucune version, npm installe la dernière version disponible dans le registre de package (https://www.npmjs.com par défaut), qui est généralement la version que vous souhaitez utiliser. Un cas spécifique durant lequel vous devez spécifier la version du package est lorsque vous utilisez npm-shrinkwrap.json et que vous souhaitez mettre à niveau un package existant vers une version plus récente. Par défaut, npm installe la version répertoriée dans le fichier npm-shrinkwrap.json. Spécifiez le numéro de version dans la commande npm installe, comme npm installe angular@1.5.9 --save, pour installer ce package et mettre à jour le numéro de version dans le fichier npm-shrinkwrap.json.

Utilisation des packages internes

Au fur et à mesure que votre équipe développe des solutions côté client, vous allez probablement créer des bibliothèques de code communes que vous souhaitez réutiliser dans l’ensemble de votre projet. Dans de nombreux cas, ces bibliothèques contiennent du code propriétaire non partagé publiquement en dehors de l’organisation, au-delà des bundles déployés en production. Lorsque vous travaillez avec des projets SharePoint Framework, il existe plusieurs façons dont votre équipe peut tirer parti de vos bibliothèques internes dans leurs projets.

Hébergement d’un registre de package privé

Dans le passé, de nombreuses organisations qui créaient des solutions .NET hébergeaient des référentiels NuGet privés pour tirer parti du système de gestion de package NuGet pour leurs packages internes. Tout comme SharePoint Framework utilise npm pour la gestion de package, de la même façon les organisations peuvent utiliser un registre privé pour leurs packages internes. Les packages développés en interne peuvent être publiés dans le registre privé et utilisés dans tous les projets au sein de l’organisation.

Lorsque vous utilisez des registres de package privés, les organisations peuvent choisir différentes offres hébergées dans le cloud ou elles peuvent héberger leur propre registre sur leur propre infrastructure.

L’utilisation d’un registre de packages privé permet aux organisations de gérer de manière centralisée le code commun utilisé dans les différents projets. En définissant un plan de gouvernance distinct autour de la contribution aux modifications apportées à la base de code partagée, les organisations peuvent s’assurer que la bibliothèque de code est de haute qualité et qu’elle offre tous les avantages pour les développeurs comme prévu plutôt que de ralentir les projets.

Les organisations qui se servent de Visual Studio Team Services ou de Team Foundation Server peuvent facilement créer un Registre npm privé directement dans VSTS/TFS. Les organisations qui utilisent d’autres systèmes de contrôle des sources peuvent utiliser d’autres solutions pour l’hébergement des packages. Un registre privé courant hébergé dans le cloud est npm Enterprise. Les organisations qui souhaitent héberger leur registre elles-mêmes peuvent choisir parmi un grand nombre d’implémentations open source telles que Sinopia ou sa copie Verdaccio ou Nexus.

Notes

différents moteurs pour l’hébergement des registres de package privés sont dans différentes phases de développement et vous devez soigneusement évaluer si le moteur en question répond à vos besoins, d’un point de vue de la fonctionnalité, de la licence et du support.

Pour simplifier l’installation et la gestion d’un registre de package privé, la plupart des moteurs proposent des images Docker prêtes à l’emploi.

Vous pouvez lier des packages au lieu d’utiliser un registre privé. La liaison de packages n’implique pas la configuration d’un registre, mais elle exige une coordination minutieuse sur tous les ordinateurs des développeurs et le serveur de build.

Tout d’abord, chaque développeur de l’équipe doit obtenir une copie du package partagé sur son ordinateur de développement. Dans la ligne de commande, il doit modifier le répertoire de travail et indiquer celui du package partagé, puis exécuter la commande npm link. Cette commande enregistre le package spécifique en tant que package global sur cet ordinateur de développement. Ensuite, les développeurs doivent modifier le répertoire de travail en spécifiant le répertoire du projet dans lequel il souhaite utiliser le package partagé. Puis ils installent le package de la même manière qu’ils installeraient n’importe quel autre package en exécutant la commande npm installe <shared_package> --enregistrer dans la ligne de commande. Comme le package partagé est installé globalement, npm utilise cette version comme source d’origine pour installer le package. À ce stade, du point de vue du projet, le package est installé comme n’importe quel autre package public et les développeurs peuvent choisir comment ils souhaitent regrouper le package avec le projet.

La liaison du package doit être exécutée sur tous les ordinateurs de développement, ainsi que sur le serveur de build. Si le package partagé n’est pas lié à l’aide de la commande npm link, la restauration des dépendances du projet ne peut pas interrompre le build.

Le référencement des packages liés est utile au début du projet lorsque vous développez le package partagé et le projet en même temps. Grâce à la liaison, vous n’avez pas besoin de publier la nouvelle version du package dans le Registre afin d’utiliser le code le plus récent dans votre projet. Il est important de garder à l’esprit que si les développeurs référencent une version de la bibliothèque partagée qu’ils ont modifiée localement et qu’ils n’ont pas validée dans le contrôle de code source, cela interrompt la génération pour le reste de l’équipe.

Combinaison d’un registre de package privé et de packages de liaison

Vous pouvez combiner des packages de liaison et un registre privé. Par exemple, vous pouvez travailler de la façon suivante : les développeurs font référence à un package lié et le serveur de build récupère la bibliothèque partagée à partir d’un registre privé. Rien ne change du point de vue du projet : la référence du package dans le fichier package.json peut être résolue à la fois à partir d’un package lié et à partir d’un registre privé. La seule chose que votre équipe doit garder à l’esprit est qu’elle doit publier les dernières modifications apportées à la bibliothèque partagée dans le registre privé avant d’exécuter le build.

Au fur et à mesure que le code de la bibliothèque partagée se stabilise au fil du temps et qu’un nombre moins important de modifications est nécessaire pour répondre aux besoins des projets spécifiques, les développeurs ont plus tendance à simplement faire référence au package publié du registre privé qu’à le modifier.

Vérification de la qualité et de la cohérence du code

Les équipes de développement logiciel orientent souvent leurs efforts sur le maintien de la cohérence et de la qualité de leurs projets. Différents développeurs ont des styles de codage et des préférences différents. Chaque équipe est constituée d’individus plus ou moins qualifiés et de développeurs plus ou moins expérimentés dans le domaine en question. En outre, de nombreuses organisations ou secteurs ont des règlements spécifiques que le logiciel doit respecter. Tous ces défis rendent le travail des développeurs plus difficile. Notamment lorsque la date d’échéance est proche, les développeurs ont tendance à agir au détriment de la qualité, ce qui, à long terme, est encore plus mauvais que de ne pas respecter les délais.

Choix de la bibliothèque JavaScript pour votre équipe et utilisation de normes de codage

Si votre équipe a créé des personnalisations SharePoint par le passé, vous avez probablement des normes de codage qui décrivent la façon dont vous créez des personnalisations et les outils et bibliothèques que vous utilisez dans vos projets. L’utilisation de normes de codage vous permet d’éliminer les préférences personnelles des développeurs individuels du code, ce qui facilite la récupération par d’autres membres de votre équipe. Vos normes de codage reflètent également l’expérience que votre équipe a recueillie au fil des années, ce qui vous permet de créer des personnalisations plus efficacement et de meilleure qualité.

Contrairement aux autres modèles de personnalisation SharePoint disponibles à ce jour, SharePoint Framework se concentre sur le développement côté client. Même si ce n’est pas strictement obligatoire, SharePoint Framework recommande d’utiliser TypeScript pour permettre aux développeurs d’écrire du meilleur code et de détecter les éventuelles incohérences dès le processus de création. Il existe également des centaines de bibliothèques côté client disponibles pour accomplir la même tâche. Si votre équipe a effectué un développement côté client dans le passé, vous avez peut-être déjà une préférence pour une bibliothèque particulière. Si ce n’est pas le cas, il peut être utile pour vous de rechercher quelques-unes des bibliothèques les plus populaires et d’en sélectionner une pour votre équipe ou de préférence pour l’ensemble de l’organisation.

En utilisant la même bibliothèque dans tous vos projets, vous facilitez l’intégration de nouveaux membres d’équipe et l’échange de membres d’équipe entre les projets. À mesure que vous acquérez plus d’expérience avec le développement côté client, votre organisation pourra en bénéficier dans tous ses projets. La standardisation de vos projets dans l’ensemble de l’organisation réduit également le temps de livraison et réduit les coûts de maintenance de vos projets. De nouvelles bibliothèques sont publiées sur Internet tous les jours et si vous passez toujours d’une bibliothèque à l’autre, vous vous retrouvez à travailler de manière inefficace pour fournir des solutions de mauvaise qualité.

La standardisation des bibliothèques utilisées au sein de votre organisation vous aide également à optimiser les performances de vos solutions. Étant donné que la même bibliothèque est utilisée dans toute l’organisation, les utilisateurs n’ont besoin de la télécharger qu’une seule fois, ce qui accélère considérablement le temps de chargement des solutions, améliorant ainsi l’expérience utilisateur.

Le choix de l’une des bibliothèques les plus populaires vous permet de réutiliser les connaissances et l’expérience d’autres développeurs qui utilisent cette bibliothèque depuis plus longtemps et qui ont déjà résolu un grand nombre des problèmes que vous rencontrerez probablement vous-même. En outre, pour les bibliothèques les plus populaires, il existe des normes de codage disponibles que votre équipe peut adopter. En utilisant les normes de marché existantes pour la bibliothèque particulière, vous facilitez la croissance de votre équipe par votre organisation en embauchant des développeurs et en les aidant à devenir plus productifs plus rapidement.

Par exemple, pour créer des solutions internes sur SharePoint Framework, Microsoft a choisi React. De nombreuses autres équipes Microsoft telles que OneDrive ou Delve utilisent Également React dans leurs projets. Cela ne signifie pas que vous devez également utiliser React dans tous vos projets SharePoint Framework, mais cela prouve l’importance de choisir une bibliothèque côté client qui fonctionne pour votre organisation. Si votre équipe a par exemple une expérience avec Angular ou Knockout, il n’y a aucune raison pour laquelle vous ne devriez pas tirer parti de cette expérience et rester productif lors de la création de solutions SharePoint Framework.

Mettez en œuvre des stratégies et des normes de codage tout au long du cycle de vie de votre solution

L’utilisation de normes de codage vous offre des avantages clairs, mais le simple fait d’avoir des normes de codage ne signifie pas qu’elles sont activement utilisées tout au long du processus de développement et de test d’une personnalisation SharePoint. Plus les développeurs attendent longtemps et plus il est difficile pour votre équipe de vérifier que votre solution respecte les normes de codage et les stratégies organisationnelles de votre équipe, plus il est coûteux de corriger les défauts détectés dans le projet. Voici quelques moyens que votre équipe doit utiliser dans le cadre de son processus de développement pour appliquer le plan de gouvernance pour la solution SharePoint.

Linting

Le linting est le processus qui consiste à vérifier que le code répond à des règles spécifiques. Par défaut les projets SharePoint Framework sont créés à l’aide de TypeScript. Sur chaque build, TSLint (le linteur pour TypeScript) analyse le projet par rapport à l’ensemble de règles prédéfini et signale les éventuelles incohérences. Les développeurs peuvent choisir les règles qu’ils souhaitent activer et peuvent créer, si nécessaire, leurs propres règles qui reflètent les directives de leur équipe ou organisation.

Les développeurs peuvent utiliser le linting pour vérifier, entre autres, le contenu des fichiers TypeScript. Il existe des linteurs pour les langages les plus populaires comme CSS, JavaScript ou Markdown, et si votre équipe a des instructions spécifiques pour ces langages, il serait intéressant de les implémenter dans un linteur afin qu’ils puissent être validés automatiquement chaque fois qu’un développeur crée le projet.

Test automatisé

Les tests automatisés permettent aux développeurs de vérifier facilement que tous les éléments continuent à fonctionner comme prévu après l’application des dernières modifications au projet. Plus le projet prend de l’ampleur, plus les tests automatisés deviennent importants : avec l’extension de la base de code, chaque modification a un impact plus important et risque d’affecter d’autres éléments de code. Les tests automatisés permettent aux développeurs de vérifier que la solution fonctionne correctement et de détecter les éventuels problèmes dès le début.

L’infrastructure SharePoint offre un support standard pour l’exécuteur de test Karma et l’infrastructure Mocha que les développeurs peuvent utiliser pour écrire des tests. Si nécessaire, les développeurs peuvent utiliser des blocs de création supplémentaires fournis avec SharePoint Framework, comme Jest et PhantomJS, pour étendre davantage la couverture de leurs tests. Tous les tests dans les projets SharePoint Framework peuvent être exécutés en utilisant la tâche gulp test standard.

Analyse du code

Lorsque le linting est utile pour valider la syntaxe du fichier particulier, les développeurs ont souvent besoin d’un support supplémentaire pour vérifier que le projet dans son ensemble respecte les instructions. En règle générale, les linters se concentrent sur le code lui-même, mais manquent le contexte de ce que représente le fichier de code particulier. Dans SharePoint Framework, les artefacts de solutions ont des exigences spécifiques, par exemple un composant WebPart doit avoir un ID unique dans le projet. En outre, les organisations peuvent avoir d’autres exigences, telles que ne pas référencer des scripts à partir du CDN ou uniquement à l’aide d’une version spécifique d’une bibliothèque particulière. C’est là que les linters sont généralement courts et que les développeurs ont besoin d’autres outils.

SharePoint Code Analysis Framework (SPCAF) est une solution tierce fréquemment utilisée par les développeurs, les administrateurs et les employés dans l’assurance qualité et les rôles de sécurité pour vérifier que les personnalisations de SharePoint respectent les directives de qualité de l’organisation. SPCAF s’intègre dans le processus entier du cycle de vie de l’application et permet aux organisations de réduire le coût total de possession des personnalisations de SharePoint. SPCAF propose un ensemble de règles qui visent spécifiquement les solutions d’infrastructure SharePoint.

Mise à niveau des projets SharePoint Framework

Le déploiement d’une personnalisation de SharePoint en production n’équivaut généralement pas à la fin de son cycle de vie. Les exigences changent fréquemment ou de nouvelles exigences sont ajoutées dans les deux cas, entraînant des modifications de la solution. Pour mettre à jour correctement une personnalisation précédemment déployée en production, les développeurs doivent tenir compte d’un certain nombre d’éléments.

SemVer (Semantic versioning - gestion sémantique des versions)

À quelques exceptions près, SharePoint Framework utilise le contrôle de version sémantique (SemVer) pour le suivi des numéros de version. Le contrôle de version sémantique est un modèle de contrôle de version largement adopté par les développeurs de logiciels dans le monde entier. Un nombre SemVer se compose de trois nombres MAJOR. Mineur. PATCH et étiquettes facultatives, par exemple, 1.0.1.

Notes

l’infrastructure SharePoint prend actuellement en charge uniquement l’utilisation des trois chiffres sans les étiquettes.

Différentes parties d’un numéro SemVer sont augmentées en fonction du type de modification appliquée à la solution :

  • MAJOR, si les modifications ne sont pas à compatibilité descendante
  • MINOR, si les modifications ajoutent de nouvelles fonctionnalités à compatibilité descendante
  • PATCH, si les modifications sont des correctifs de bogues à compatibilité descendante

Il est important de garder à l’esprit que SemVer est simplement un contrat. C’est à votre équipe de le suivre pour indiquer clairement les modifications dans la dernière version.

Vous pouvez en savoir plus sur la gestion sémantique des versions sur http://semver.org.

Augmentation du numéro de version

Lors de la mise à jour d’une partie d’une solution SharePoint Framework, les développeurs doivent augmenter les numéros de version des éléments concernés pour indiquer clairement ceux qui ont été modifiés et l’impact de ces changements.

Augmentation de la version du package dans package.json

Le package d’infrastructure SharePoint est structuré comme un package Node.js. Ses dépendances et les métadonnées sont stockées dans le fichier package.json dans le dossier du projet. L’une des propriétés dans le fichier package.json est la propriété de version indiquant la version de l’ensemble du projet. Par défaut, tous les composants de la solution actuelle héritent de ce numéro de version. Les développeurs doivent augmenter le numéro de version dans le fichier package.json chaque fois qu’une nouvelle version du projet est planifiée, conformément à la convention SemVer.

Augmentation de la version du package de la solution dans package-solution.json

Les solutions SharePoint Framework sont déployées à l’aide d’un fichier *.sppkg installé dans le catalogue d’applications sur un client SharePoint. Un fichier *.sppkg est semblable à un package de complément SharePoint et suit les mêmes conventions de gestion de versions. La version actuelle du package *.sppkg est définie à l’aide d’un numéro composé de quatre parties (MAJOR.MINOR.REVISION.BUILD) stocké dans le fichier config/package-solution.json. Par souci de clarté, les développeurs doivent garder ce numéro synchronisé avec le numéro de version dans le fichier package.json, car les deux numéros font référence à la version du projet dans son ensemble.

Notes

L’augmentation du numéro de version dans le fichier package-solution.json entre les versions est requise pour que la nouvelle version du package puisse être déployée correctement dans SharePoint.

Mise à jour des dépendances

L’une des raisons expliquant la mise à jour d’un projet d’infrastructure SharePoint peut être la modification de l’une des dépendances sous-jacentes (par exemple, une nouvelle version d’Angular avec des correctifs de bogues et des améliorations des performances). Si votre équipe suit l’approche recommandée consistant à utiliser npm shrinkwrap pour le verrouillage des versions des dépendances, utilisez la commande npm installe @ --enregistrer pour mettre à jour votre dépendance vers la version spécifique et testez votre projet afin de vérifier qu’il fonctionne comme prévu avec les dernières mises à jour. Selon l’impact des modifications apportées aux dépendances sous-jacentes sur le projet, la mise à jour du projet globale peut varier d’un correctif à une version majeure complète.

Important

Ne modifiez pas manuellement les numéros de version des dépendances dans le fichier package.json. Si vous utilisez un fichier de verrouillage comme npm shrinkwrap, vos modifications manuelles au fichier package.json seront ignorées et les numéros de version enregistrés dans les fichiers de verrouillage seront utilisés à la place, ce qui entraînera des erreurs difficiles à retracer dans votre projet.

Modifications de la structure d’un projet

La mise à jour de votre projet vers une version plus récente de SharePoint Framework peut nécessiter d’apporter des modifications à la structure de votre projet et aux fichiers de configuration du projet. Avant de mettre à jour les versions de SharePoint Framework dans les dépendances de votre projet, vous devez toujours créer un projet à l’aide de la version de SharePoint Framework à laquelle vous souhaitez vous mettre à niveau et comparer avec soin sa structure et son contenu à ceux de votre projet existant. Cela vous permettra de déterminer l’impact de la mise à niveau de votre projet et d’éviter d’appliquer des modifications fatales à votre projet.

Prudence lors de l’utilisation de npm outdated

Une des méthodes pour savoir quelles dépendances de votre projet il est nécessaire de mettre à jour consiste à exécuter la commande npm outdated. Cette commande analyse l’arborescence des dépendances et vous indique quels packages peuvent être mis à jour. Cette commande est très pratique, mais elle doit être effectuée avec précaution.

Depuis SPFx v 1.3, le générateur Yeoman pour SharePoint Framework vous permet de choisir si vous souhaitez générer un projet qui doit fonctionner uniquement dans SharePoint Online ou à la fois dans SharePoint Online et SharePoint 2016 Feature Pack 2 et versions ultérieures. SharePoint hébergé en local utilise une version de SharePoint Framework plus ancienne que la dernière version disponible dans SharePoint Online. Si vous exécutez la commande npm outdated sur un projet compatible avec SharePoint en local, elle vous conseillera de mettre à jour tous les packages principaux de SharePoint Framework vers les dernières versions publiées sur npm. Malheureusement, en mettant à jour ces packages vers leurs versions les plus récentes, votre projet ne fonctionnerait plus avec SharePoint en local. Avant de mettre à jour les versions des packages de SharePoint Framework, vous devez toujours vérifier si votre projet est destiné à utiliser SharePoint hébergé en local. Si c’est le cas, vérifiez quelle version de SharePoint Framework vous devez prendre en charge.

Création d’un package de projet en mode publication

Une fois que vous avez vérifié que la solution fonctionne comme prévu, créez le projet en mode publication à l’aide de la commande gulp bundle --ship. Créez ensuite un nouveau package à l’aide de la commande gulp package-solution--Ship. Sans exécuter la commande gulp bundle --ship en premier lieu, le package inclut une version antérieure de votre projet.

Déploiement de la nouvelle version de votre solution

Après la création du package du projet, l’étape suivante consiste à le déployer. Tout d’abord, déployez les groupes de composants WebPart mis à jour situés dans le dossier ./temp/deploy dans votre projet. Publiez les fichiers à côté des groupes de composants WebPart de la version précédente de votre solution.

Notes

vous ne devez pas supprimer les versions précédentes de votre solution tant que des instances actives de composants WebPart les utilisent. Chaque version des fichiers groupés possède un nom unique et la suppression des versions antérieures avant la mise à jour des composants WebPart interrompra ces composants WebPart.

Ensuite, déployez le nouveau package de solution dans le catalogue d’applications SharePoint. Cela est nécessaire pour informer SharePoint de la nouvelle version de la solution, qu’elle doit appliquer.