Implémenter une intégration continue et un déploiement continu à l’aide d’Azure DevOps
Azure DevOps (Visual Studio Team Services / Team Foundation Server) se compose d’un ensemble d’outils et services qui aident les développeurs à implémenter des processus DevOps, intégration continue et déploiement continue pour leurs projets de développement.
Cet article explique comment procéder pour configurer votre environnement Azure DevOps avec l’intégration continue et déploiement continu pour automatiser votre infrastructure SharePoint, tests unitaires et déploiement.
Choisir entre les Azure Multi-Stage Pipelines (en préversion) et les builds Azure DevOps, et les versions
Deux approches sont actuellement disponibles pour implémenter l’intégration continue et le déploiement dans Azure DevOps.
Historique, Azure construit et publie est une édition graphique qui stocke les définitions dans un document JSON caché à l'utilisateur.
Les deux approches sont décrites pour SharePoint Framework :
- Build et version Azure (cet article)
- Pipelines Azure multi-étapes
Intégration continue
Intégration continue (CI) permet aux développeurs d’intégrer le code dans un référentiel partagé en vérifiant automatiquement la construction à l’aide de tests unitaires et en emballant la solution à chaque fois que de nouvelles modifications du code sont soumises.
La configuration d’Azure DevOps pour l’intégration continue avec une solution SharePoint Framework nécessite les étapes suivantes :
- Création de la définition de construction
- L’installation NodeJS
- Restauration des dépendances
- L’exécution des tests unitaires
- Importation de résultats de test
- L’importation d’informations de couverture de code
- Groupement de la solution
- Emballage de la solution
- Préparer les artefacts
- Publier les artefacts
Création de la définition de construction
La définition de Build, comme son nom l’indique, inclut les définitions et leurs configurations pour la construction. Commencer la configuration de votre intégration continue en créant une définition de construction et en la liant à votre référentiel.

Notes
Les définitions de construction peuvent être décrites comme modèle. Il s’agit d’un ensemble de tâches configurées qui seront exécutées l’une après l’autre sur le code source à chaque fois qu’une construction est déclenchée. Le tâches peuvent être regroupées en phases, par défaut une définition de construction contient au moins une même phase. Vous pouvez ajouter de nouvelles tâches à la phase en cliquant sur le signe plus volumineux à côté du nom de la phase.
Installation de NodeJS version 10
Une fois que la définition de construction a été créée, la première chose que vous avez à faire est installer NodeJS. Veillez à installer la version 10, car SharePoint Framework en dépend.

Notes
Vérifiez que vous spécifiez 10.x dans le champVersion Spec. Si votre projet est basé sur SharePoint Framework 1.7.1 ou une version antérieure, utilisez la version 8.x.
Restauration des dépendances
Comme les dépendances de logiciels tierces ne sont pas stockés dans le contrôle source, vous devez les restaurer avant de commencer à créer le projet. Pour cela, ajoutez une tâche npm et paramétrez la commande sur install.

Exécution des tests unitaires
L’infrastructure SharePoint ne propose pas une infrastructure de test par défaut (depuis la version 1.8.0), nous pourrons tirer parti de Jest avec cet exemple. Ces modules seront installés plus tard et sont vivement recommandés, au moins pour tester la logique métier de votre code pour recueillir des commentaires sur des problèmes ou régressions potentiels dès que possible. Pour que Azure DevOps exécute vos tests unité, ajoutez une tâche npm. Définir le command à custom et custom command, entrez test. Puis définissez l’option Working Directory à $(Build.SourcesDirectory).

Configuration de Jest
Par défaut, les projets SharePoint Framework n’incluent pas d’infrastructure de test. Nous pourrons tirer parti de Jest dans cet exemple.
npm i jest jest-junit @voitanos/jest-preset-spfx-react16 -D
Notes
Les projets générés dans SharePoint Framework 1.7.1 et versions antérieures s’appuient sur la version 15 de React. Si vous utilisez React 15, vous devez installer @voitanos/jest-preset-spfx-react15 à la place. Pour les autres infrastructures (Knockout,...), vous devrez peut-être installer un autre paramètre prédéfini à sa place.
Vous devez également configurer Jest, pour cela créez un fichier config/jest.config.json et ajoutez le contenu suivant.
{
"preset": "@voitanos/jest-preset-spfx-react16",
"rootDir": "../src",
"coverageReporters": [
"text",
"json",
"lcov",
"text-summary",
"cobertura"
],
"reporters": [
"default",
["jest-junit", {
"suiteName": "jest tests",
"outputDirectory": "temp/test/junit",
"outputName": "junit.xml"
}]
]
}
Vous devez également configurer votre projet pour tirer parti de jest lorsque vous tapez des commandes. Pour ce faire, modifier le fichier package.json et ajouter/remplacer ces deux scripts avec les valeurs suivantes :
"test": "./node_modules/.bin/jest --config ./config/jest.config.json",
"test:watch": "./node_modules/.bin/jest --config ./config/jest.config.json --watchAll"
Écrire un test unitaire
Pour rédiger votre premier test unitaire, créer un fichier src/webparts/webPartName/tests/webPartName.spec.ts et ajoutez le contenu suivant :
import 'jest'
describe("webPartName", () => {
test("should add numbers Sync fluent", () => {
const result = 1 + 3;
expect(result).toBe(4); // fluent API
});
});
Notes
Vous pouvez en apprendre plus sur l’écriture de tests unitaires à l’aide de Jest ici. Vous pouvez en apprendre davantage sur le test des applications réactives avec Jest et Enzyme ici (vous pouvez ignorer la partie configuration).
Importation de résultats de test
Pour que les données de résultats de test soient attachées aux résultats de la build, vous devez importer les résultats des tests des exécuteurs de test dans Azure DevOps. Pour cela, ajouter une nouvelle tâche Publish Test Results. Définir le champ Test results files à **/junit.xml et le Search folder à $(Build.SourcesDirectory).

L’importation d’informations de couverture de code
Afin que la couverture de code soient signalée avec le statut build, vous devez ajouter une tâche pour importer ces informations. Pour configurer les informations de couverture du code, ajoutez les tâchespublish code coverage results. Vérifiez que vous définissez l’outil sur Cobertura, Summary files à $(Build.SourcesDirectory)/**/*-coverage.xml.

Groupement de la solution
Vous devez d’abord regrouper votre solution afin de profiter des biens statiques pouvant être compris par un navigateur web. Ajouter une autre tâchegulp, définissez le chemin d’accèsgulpfile, définissez le champGulp Tasks à regrouper et ajoutez --ship dans le Arguments.

Emballage de la solution
À présent que vous avez des biens statiques, l’étape suivante consiste à combiner les biens dans un pack que SharePoint pourra déployer. Ajoutez une autre tâchegulp, définissez le chemin d’accèsgulpfile, définissez le champGulp Tasks à regrouperpackage-solution et ajoutez --ship dans le Arguments.

Préparer les artefacts
Par défaut, une version Azure DevOps ne conserve pas tous les fichiers. Pour vous assurer que les fichiers requis nécessaires pour la publication sont conservés, vous devez indiquer explicitement quels fichiers doivent être conservés.
Ajouter une tâcheCopy Files et définissez Contents à **\*.sppkg (le pack SharePoint créé avec la tâche précédente) et le dossier cible à $(build.artifactstagingdirectory)/drop.

Publier les artefacts
À présent que vous avez recueilli tous les fichiers nécessaires pour le déploiement dans un dossier spécial artefacts, vous devez demander à Azure DevOps de conserver ces fichiers après l’exécution de la construction. Pour cela, ajoutez une tâche Publish artifacts et paramétrez Path to publish à $(build.artifactstagingdirectory)/drop et Artifact name à drop.

Déploiement continu
Déploiement continu (CD) prend les packs de codes validés du processus de construction et les déploie dans un environnement intermédiaire ou de production. Les développeurs peuvent suivre si les déploiements ont réussi ou non et affiner les problèmes aux versions package en particulier.
La configuration d’Azure DevOps pour les déploiements continus avec une solution SharePoint Framework nécessite les étapes suivantes :
- Création de la définition de publication
- Liaison de l’artefact Build
- Création de l’environnement
- Installation NodeJS
- Installation de la CLI pour Microsoft 365
- Connexion du catalogue d’applications
- Ajouter un pack de solutions au catalogue d’applications
- Déploiement de l’application
- Définition des variables pour l’environnement
Création de la définition de publication
Commencez par créer une définition de publication avec un modèle vide. Une définition de publication est un processus qui est utilisé pour identifier les éléments suivants pour le déploiement :
- Environnement
- Tâches de déploiement
- Artefacts Build

Liaison de l’artefact Build
Cliquez sur Add an artifact et sélectionnez la définition de build que vous avez précédemment créée. Notez le Source Alias nom défini, car vous devrez l’utiliser dans les tâches suivantes.

Création de l’environnement
Lorsque vous créez votre environnement de déploiement continu, vous pouvez donner un nom et configurer les approbations préalables au déploiement, filtres d’artefacts (c'est-à-dire déployer uniquement si la build provient de telle ou telle branche), etc. en cliquant sur les boutons autour de la zone de l’environnement ou directement sur le titre.

Installation NodeJS
En cliquant sur 1 job, 0 tasks vous pouvez accéder à l’affichage de configuration de tâches, qui fonctionne de la même façon pour la définition de build. Ici, vous pouvez sélectionner l’ensemble de tâches qui s’exécute uniquement pour cet environnement spécifique. Cela inclut l’installation de NodeJS 10 ou version ultérieure.
Ajouter une tâche Node tool installer et définir 10.X dans le Version Spec champ. Si votre projet est basé sur SharePoint Framework version 1.7.1 ou une version antérieure, utilisez la version 8.X.

Installation de la CLI pour Microsoft 365
L’interface Microsoft 365 langue courante (CLI) est un projet open source développé par la Communauté Microsoft 365 PnP. Pour tirer parti de l’infrastructure CLI dans le cadre de votre définition de publication, vous devez tout d’abord l’installer. Ensuite, vous pourrez tirer parti des commandes disponibles pour gérer le déploiement. Ajouter une tâchenpm , sélectionnez une commande Custom et tapez install -g @pnp/cli-microsoft365 dans le Command and Arguments champ.

Notes
En savoir plus sur la CLI pour Microsoft 365
Connexion à SharePoint Online
Avant d’utiliser le catalogue d’applications dans un environnement de déploiement, vous devez d’abord vous authentifier contre le catalogue d’applications de votre client. Pour ce faire, ajoutez une tâche Command Line et collez-la dans la commande suivante dans script, champ m365 login -t password -u $(username) -p $(password).

Notes
Si vous utilisez CLI pour Microsoft 365 pour vous connecter à votre client pour la première fois, vous devez d’abord effectuer une connexion interactive avec le compte. Cela est nécessaire pour accorder l’accès à l’application PnP Office 365 Management Shell utilisée par CLI pour Microsoft 365 pour accéder au client au nom du compte. Sinon, la connexion non interactive échouera. Détails disponibles sur l’ILC pour Microsoft 365 Guide de l’utilisateur.
Notes
L’interface CLI pour Microsoft 365 est une solution open source pour laquelle un support est assuré par la communauté active. Il n’existe pas de contrat SLA Microsoft pour le support technique relatif à cet outil open source.
Ajouter un pack de solutions au catalogue d’applications
Télécharger le pack de solution à votre catalogue en ajoutant une autre Command Line tâche et coller la ligne de commande suivante dans le Script champ m365 spo app add -p $(System.DefaultWorkingDirectory)/SpFxDevOps/drop/SharePoint/solution/sp-fx-devops.sppkg --overwrite
Notes
Le chemin d’accès du pack dépend du nom de votre solution (voir la configuration de votre projet) ainsi que du Source Alias défini précédemment, assurez-vous qu’ils correspondent.
Notes
Vous pouvez télécharger une solution vers un catalogues d’applications de collection de sites en ajoutant --appCatalogUrl https://$(tenant).sharepoint.com/$(catalogsite) --scope sitecollection

Déploiement de l’application
La dernière étape d’installation consiste à déployer l’application dans le catalogue pour la rendre accessible à toutes les collections de sites du client en tant que dernière version. Ajouter une autre Command Line tâche et coller ci-dessous la ligne de commande dans le Script champ m365 spo app deploy --name sp-fx-devops.sppkg
Notes
Vérifiez que vous mettez à jour le nom du pack.
Notes
Vous pouvez déployer une solution à partir d’un catalogues d’applications de collection de sites en ajoutant --appCatalogUrl https://$(tenant).sharepoint.com/$(catalogsite) --scope sitecollection

Définition des variables pour l’environnement
Les tâches que vous avez configurées dans la dernière étape dépendent des variables de processus Azure DevOps (facilement identifiées avec la $(variableName) syntaxe). Vous devez définir ces variables avant de pouvoir exécuter la définition de build. Pour ce faire, cliquez sur l’Variables onglet.
Ajoutez les variables suivantes
| Nom | Valeur |
|---|---|
| catalogsite | Facultatif. Chemin d’accès relatif au serveur du site du catalogue d’applications, par exemplesites/appcatalog lors du chargement vers un catalogue d’applications de collection de sites |
| mot de passe | Mot de passe de l’utilisateur avec des autorisations administratives sur le client, n’oubliez pas de vérifier le verrouillage pour masquer à d’autres utilisateurs |
| username | Nom d’utilisateur de l’utilisateur avec des autorisations administratives sur le client |
| client | Facultatif. Nom du client https://tenant.sharepoint.compar exempletenant, lors du téléchargement vers un catalogue d’applications de collection de sites |

Notes
Vérifiez que vous enregistrez votre définition de publication.
Tests
Pour tester le processus de déploiement continu nouvellement créé, revenez à la Builds section Azure DevOps, sélectionnez votre définition de build, cliquez sur Queue. Sélectionnez votre branche, cliquez sur Queue. Une nouvelle build est créée et commencera à être construite.

Après quelques minutes, votre build doit se valider et afficher une page de résultats de ce type.

Si vous accédez à la Release section Azure DevOps, une nouvelle version doit avoir démarré automatiquement. Après quelques minutes votre publication devrait être validée et votre solution SharePoint Framework est déployée à votre client.

Votre pipeline DevOps pour votre solution SharePoint Framework est désormais configurée dans Azure DevOps et prête à être personnalisée pour correspondre à votre modèle.