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 aux autres modèles de développement SharePoint disponibles à ce jour, le SharePoint Framework se concentre sur le développement côté client et repose sur des outils open source populaires tels que Gulp et webpack. L’un des grands avantages de cette modification est que les développeurs sur n’importe quelle plateforme peuvent créer des personnalisations SharePoint.

SharePoint Framework est un modèle de développement. Malgré les différences dans la technologie sous-jacente, les mêmes concepts que ceux des autres modèles de développement utilisés par les développeurs de SharePoint par le passé s’appliquent quand vous l’utilisez pour générer des solutions. Les développeurs utilisent la chaîne d’outils de l’infrastructure SharePoint pour créer et tester leurs solutions. Une fois prêts, ils cèdent le package de solution à déployer au client SharePoint pour procéder aux tests et à la publication.

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 faire référence à tous les différents packages dans les versions correctes. Lors de la création de la structure de nouveaux projets, le générateur Yeoman pour infrastructure SharePoint ajoute automatiquement les références nécessaires au package à partir de la version correspondante de l’infrastructure SharePoint. Néanmoins, pendant la mise à niveau du projet vers une version plus récente de SharePoint Framework, les développeurs doivent être encore plus attentifs pour mettre à jour correctement les numéros de version des packages de SharePoint Framework.

Préparation de l’environnement de développement

Pour créer des SharePoint Framework les développeurs de solutions, ont besoin d’outils spécifiques sur les machines 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 des solutions sont 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 le projet .NET et est responsable de l’exécution de tâches telles que la création ou l’empaquetage d’un projet SharePoint Framework. Gulp est distribué en tant que 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éé peut être incohérent avec le reste du projet, ce qui peut même entraîner des erreurs de génération. Il existe un certain nombre de façons de contourner cette limitation, que cet article décrit plus loin.

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. SharePoint Framework projets sont fournis avec leur propre version de TypeScript, qui est utilisée dans le processus de génération et qui n’oblige pas les développeurs à l’installer 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 des logiciels supplémentaires pour correspondre à l’environnement cible où la solution s’exécuterait aussi étroitement 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 le SharePoint Framework a ses origines dans le cloud et évolue fréquemment, 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. De cette façon, 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 la fourniture de machines de développement puissantes aux développeurs SharePoint et, dans certains cas, plusieurs développeurs devaient partager la même machine au détriment de la productivité. Avec la SharePoint Framework, les développeurs peuvent utiliser des machines de développement standard pour créer des personnalisations SharePoint.

Développement sur l’hôte

L’option la plus simple pour configurer un environnement de développement pour SharePoint Framework projets consiste probablement à 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 telles que 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 machine selon leurs préférences une seule fois et l’utiliser dans tous les projets. En outre, à mesure que le logiciel s’exécute sur l’hôte, il dispose d’un accès direct à l’uc, à la mémoire et aux E/S disque sans couche de virtualisation entre elles, ce qui permet d’obtenir de meilleures performances que lors de l’exécution du même logiciel virtualisé.

Développement dans une machine virtuelle

Auparavant, l’approche la plus courante parmi les développeurs SharePoint consistait à utiliser des machines virtuelles comme environnement de développement principal pour la création de 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é. À l’aide de machines virtuelles, ils peuvent isoler le logiciel de développement du système d’exploitation hôte, ce qui est une exigence courante, en particulier dans les grandes organisations. En créant une machine virtuelle distincte pour chaque projet, les développeurs peuvent s’assurer que la chaîne d’outils qu’ils utilisent est compatible avec le projet, même s’ils doivent récupérer le projet particulier à l’avenir.

L’utilisation de machines virtuelles n’est pas sans inconvénients. Les machines virtuelles sont volumineuses et nécessitent que les développeurs utilisent des ordinateurs suffisamment puissants pour les exécuter avec des performances acceptables pour être productifs. En outre, en particulier sur des périodes plus longues, les développeurs doivent maintenir le système d’exploitation à jour et s’assurer qu’ils exécutent toutes les mises à jour de sécurité nécessaires. Comme les développeurs travaillent sur une machine virtuelle, ils doivent passer un certain temps au début d’un nouveau projet pour configurer la machine virtuelle standard selon leurs préférences ou doivent céder à la configuration standard au détriment de leur productivité. Étant donné que les machines virtuelles exécutent un système d’exploitation complet avec tous ses composants, il est beaucoup plus difficile de s’assurer que toutes les machines virtuelles utilisées par tous les développeurs de l’équipe sont cohérentes. 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 similaire aux machines virtuelles avec quelques différences. Les avantages les plus importants de l’utilisation d’images Docker sur les machines virtuelles sont que les images Docker sont plus faciles à créer, à gérer et à distribuer, qu’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 qu’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 basé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 généré par le générateur SharePoint Framework Yeoman a des dépendances sur les packages SharePoint Framework et d’autres packages requis pour qu’il s’exécute correctement. Lorsque vous générez vos composants WebPart, vous pouvez inclure des dépendances supplémentaires telles que 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 est destinée à aider les développeurs à maintenir leurs dépendances à jour plus facilement. L’une des conséquences de cette approche est que la restauration des dépendances pour le même projet à deux moments dans le temps peut donner des résultats différents, ce qui peut même entraîner la rupture 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 un autre système d’exploitation, l’inclusion du dossier node_modules dans le contrôle de code source risque d’interrompre la génération 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.

Certains packages sont compilés dans des 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 de créer le projet sur votre hôte Windows, vous obtenez une erreur signalant l’incompatibilité dans le type d’environnement utilisé pour créer 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.

Pour ajouter un package à votre projet SharePoint Framework exécutez la commande npm install {package} --save ou npm install {package} --save-dev dans la ligne de commande, par exemple : npm install angular --save. 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

Lorsque votre équipe développe des solutions côté client, vous créez très probablement des bibliothèques de code courantes que vous souhaitez réutiliser dans tout votre projet. Dans de nombreux cas, ces bibliothèques contiennent un code propriétaire qui n’est pas partagé publiquement en dehors de l’organisation, au-delà des fichiers groupés déployés en production. Lorsque vous travaillez avec des projets d’infrastructure SharePoint, il existe plusieurs façons pour votre équipe de tirer parti de vos bibliothèques internes dans ses 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.

Les organisations peuvent avoir recours à un registre de package privé pour gérer de façon centralisée le code courant utilisé dans les différents projets. En définissant un plan de gouvernance distinct qui participe aux changements apportés à la base de code partagée, les organisations peuvent garantir que la bibliothèque de code est de haute qualité et qu’elle offre des avantages à tous les développeurs comme prévu, au lieu d’être une charge ralentissant 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.

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.

Liaison de packages à l’aide du lien NPM

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é. Ensuite, ils installent le package de la même façon qu’ils installent n’importe quel autre package en exécutant la commande npm install {shared_package} --save 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.

Référencer des packages liés est utile aux premiers stades du projet lorsque vous développez le package partagé et le projet simultanément. Grâce à la liaison, vous n’avez pas besoin de publier la nouvelle version du package dans le registre pour utiliser le dernier code dans votre projet. Il convient de tenir compte du risque suivant : si les développeurs font référence à une version de la bibliothèque partagée qu’ils ont modifiée localement et qu’ils n’ont pas lié au contrôle source, le build est interrompu 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 d’une manière où les développeurs référencent un package lié et où le serveur de build extrait la bibliothèque partagée 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 problèmes compliquent la productivité des développeurs. 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 de SharePoint dans le passé, vous avez probablement des normes de codage qui décrivent comment créer des personnalisations, ainsi que les outils et les bibliothèques que vous utilisez dans vos projets. Les normes de codage vous permettent d’éliminer les préférences personnelles des développeurs individuels dans le code, ce qui simplifie sa sélection par d’autres membres de votre équipe. Vos normes de codage reflètent également l’expérience de votre équipe au fil des ans, 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.

L’utilisation de la même bibliothèque dans tous vos projets facilite l’intégration de nouveaux membres d’équipe et l’échange des membres d’équipe entre les projets. Au fur et à mesure que vous vous familiarisez avec le développement côté client, votre organisation peut en bénéficier dans tous ses projets. La normalisation de vos projets au sein de l’organisation entière réduit également le délai de livraison et les coûts de maintenance de vos projets. De nouvelles bibliothèques sont publiées quotidiennement sur Internet et si vous continuez à basculer entre les dernières bibliothèques, vous travaillerez de façon inefficace et fournirez des solutions de qualité médiocre.

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

En choisissant l’une des bibliothèques les plus populaires, vous pouvez réutiliser les connaissances et l’expérience d’autres développeurs qui ont utilisé cette bibliothèque pendant plus longtemps et qui ont déjà résolu de nombreux problèmes que vous rencontrerez probablement vous-même. Les bibliothèques les plus populaires ont également des normes de codage disponibles que votre équipe peut adopter. En utilisant des normes du marché existantes pour une bibliothèque particulière, vous permettez à votre organisation d’accroître plus facilement votre équipe en embauchant des développeurs et en les aidant à gagner en productivité plus rapidement.

Par exemple, pour créer des solutions internes sur l’infrastructure SharePoint, Microsoft a choisi React. De nombreuses autres équipes chez Microsoft, comme OneDrive ou Delve utilisent aussi React dans leurs projets. Cela ne signifie pas que vous devez utiliser React dans tous vos projets d’infrastructure SharePoint, mais cela prouve l’importance de choisir une bibliothèque côté client qui fonctionne pour votre organisation. Si par exemple, votre équipe a déjà utilisé Angular ou Knockout, il n’y a aucune raison pour que vous ne profitiez pas de cette expérience et ne soyez pas 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 présente des avantages clairs, mais le fait de simplement disposer de normes de codage ne signifie pas qu’elles sont utilisées activement dans le processus de développement et de test entier d’une personnalisation de SharePoint. Plus les développeurs attendent, plus il est difficile pour votre équipe de vérifier que votre solution est conforme aux normes de codage et aux stratégies organisationnelles de votre équipe, et plus il est coûteux de corriger les défauts détectés dans le projet. Voici quelques méthodes 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

Le linting est utile pour valider la syntaxe d’un fichier particulier, mais les développeurs ont souvent besoin de davantage de support pour vérifier que le projet entier est conforme aux instructions. En règle générale, les linteurs se concentrent sur le code lui-même, mais le contexte de ce que représente le fichier de code en question leur échappe. Dans les solutions d’infrastructure SharePoint, les artefacts ont des exigences spécifiques. Par exemple, un composant WebPart doit avoir un ID unique dans le projet. Les organisations peuvent également avoir d’autres exigences : par exemple, ne pas référencer les scripts de CDN ou utiliser uniquement une version spécifique d’une bibliothèque particulière. C’est dans ces situations que les linteurs ne suffisent pas 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, l’infrastructure SharePoint utilise la gestion sémantique des versions (SemVer) pour le suivi des numéros de version. La gestion sémantique des versions est un modèle de gestion des versions largement adopté par les développeurs de logiciels dans le monde entier. Un numéro SemVer est constitué de trois chiffres MAJOR.MINOR.PATCH et d’étiquettes facultatives, par exemple. 1.0.1.

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

SharePoint Framework solutions sont déployées à l’aide d’un fichier *.sppkg installé dans le catalogue d’applications sur un locataire SharePoint. Un fichier *.sppkg est similaire à un package de complément SharePoint et suit les mêmes conventions de gestion de version. La version actuelle du package *.sppkg est définie à l’aide d’un package en quatre parties (MAJOR. MINEUR. RÉVISION. BUILD) numéro 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.

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 d’utiliser npm shrinkwrap pour verrouiller les versions de dépendance, vous devez utiliser la commande npm install {package}@{version} --save pour mettre à jour votre dépendance vers la version spécifique et tester 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.

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.

Déployez ensuite le nouveau package de solution sur le catalogue d’applications SharePoint. Cela est nécessaire pour indiquer à SharePoint la nouvelle version de la solution à appliquer.