Implémenter une intégration continue et un déploiement continu à l’aide d’Azure Pipelines
Azure Pipelines est la version la plus récente des fonctionnalités de build et de publication d’Azure DevOps.
Cet article explique les étapes de la mise en place de votre environnement Azure Pipelines avec intégration et déploiement continus pour automatiser les constructions, les tests unitaires et le déploiement de votre cadre SharePoint.
Choisir entre Azure Multi-stage Pipelines et Azure DevOps constructions et rejets
Il existe actuellement deux approches pour mettre en œuvre 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.
Azure multi-stage Pipelines s'appuie sur des définitions de pipeline stockées sous forme de fichiers YAML sur le dépôt, ce qui assure la transparence, l'historique des versions et la répétabilité.
Les deux approches sont décrites pour le cadre SharePoint ::
- Build et version Azure
- Azure Multi-stage Pipelines (cet article)
Implémentation de l’intégration continue et des tests continus
L’intégration continue et la phase de test continue sont décrites dans le modèle YAML suivant.
Copiez le contenu suivant dans un nouveau fichier à la racine du projet appelé azure-pipelines-build-template.yml.
parameters:
name: ''
jobs:
- job: ${{ parameters.name }}
pool:
vmImage: 'ubuntu-latest'
demands:
- npm
- node.js
- java
variables:
npm_config_cache: $(Pipeline.Workspace)/.npm
steps:
- checkout: self
- task: NodeTool@0
displayName: 'Use Node 10.x'
inputs:
versionSpec: 10.x
checkLatest: true
- task: CacheBeta@1
inputs:
key: npm | $(Agent.OS) | package-lock.json
path: $(npm_config_cache)
cacheHitVar: CACHE_RESTORED
- script: npm ci
displayName: 'npm ci'
- task: Gulp@0
displayName: 'Bundle project'
inputs:
targets: bundle
arguments: '--ship'
- script: npm test
displayName: 'npm test'
- task: PublishTestResults@2
displayName: Publish test results
inputs:
testResultsFormat: JUnit
testResultsFiles: '**/junit.xml'
#failTaskOnFailedTests: true #if we want to fail the build on failed unit tests
- task: PublishCodeCoverageResults@1
displayName: 'Publish code coverage results'
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/*coverage.xml'
- task: Gulp@0
displayName: 'Package Solution'
inputs:
targets: 'package-solution'
arguments: '--ship'
- task: CopyFiles@2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)'
inputs:
Contents: |
sharepoint/**/*.sppkg
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: drop'
Notes
Vous pouvez commenter/supprimer les PublishCodeCoverageResults, PublishTestResults et NPM des tâches de test si vous n’avez pas de test unitaire et/ou si vous ne souhaitez pas que les tests unitaires soient exécutés.
Notes
Vous trouverez la dernière version de ce fichier sur l’exemple
Implémentation du déploiement continu
L’étape de déploiement continue est décrite dans le modèle YAML suivant.
Copiez le contenu suivant dans un nouveau fichier à la racine du projet appelé Azure-pipelines-deploy-template.yml.
parameters:
# unique name of the job
job_name: deploy_sppkg
# friendly name of the job
display_name: Upload & deploy *.sppkg to SharePoint app catalog
# name of target environment deploying to
target_environment: ''
# app catalog scope (tenant|sitecollection)
m365cli_app_catalog_scope: 'tenant'
variable_group_name: ''
jobs:
- deployment: ${{ parameters.job_name }}
displayName: ${{ parameters.display_name }}
pool:
vmImage: 'ubuntu-latest'
environment: ${{ parameters.target_environment }}
variables:
- group: ${{parameters.variable_group_name}} #m365_user_login, m365_user_password, m365_app_catalog_site_url
strategy:
runOnce:
deploy:
steps:
- checkout: none
- download: current
artifact: drop
patterns: '**/*.sppkg'
- script: sudo npm install --global @pnp/cli-microsoft365
displayName: Install CLI for Microsoft365
- script: m365 login $(m365_app_catalog_site_url) --authType password --userName $(m365_user_login) --password $(m365_user_password)
displayName: Login to Microsoft 365
- script: |
CMD_GET_SPPKG_NAME=$(find $(Pipeline.Workspace)/drop -name '*.sppkg' -exec basename {} \;)
echo "##vso[task.setvariable variable=SpPkgFileName;isOutput=true]${CMD_GET_SPPKG_NAME}"
displayName: Get generated *.sppkg filename
name: GetSharePointPackage
- script: m365 spo app add --filePath "$(Pipeline.Workspace)/drop/sharepoint/solution/$(GetSharePointPackage.SpPkgFileName)" --appCatalogUrl $(m365_app_catalog_site_url) --scope ${{ parameters.m365cli_app_catalog_scope }} --overwrite
displayName: Upload SharePoint package to Site Collection App Catalog
- script: m365 spo app deploy --name $(GetSharePointPackage.SpPkgFileName) --appCatalogUrl $(m365_app_catalog_site_url) --scope ${{ parameters.m365cli_app_catalog_scope }}
displayName: Deploy SharePoint package
Notes
Vous trouverez la dernière version de ce fichier sur l’exemple
Définir la structure de Pipeline
À présent que les étapes build et déployer sont définies dans leurs modèles respectifs, celui-ci doit être assemblé comme multi-stage pipeline.
Ce document décrit la structure du pipeline ainsi que les différents environnements utilisés.
Copiez le contenu suivant dans un nouveau fichier à la racine du projet appelé azure-pipelines.yml.
name: $(TeamProject)_$(BuildDefinitionName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)
resources:
- repo: self
trigger:
branches:
include:
- master
- develop
stages:
- stage: build
displayName: build
jobs:
- template: ./azure-pipelines-build-template.yml
parameters:
name: 'buildsolution'
- stage: 'deployqa'
# uncomment if you want deployments to occur only for a specific branch
#condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/develop'))
jobs:
- template: ./azure-pipelines-deploy-template.yml
parameters:
job_name: deploy_solution
target_environment: 'qa'
variable_group_name: qa_configuration
Notes
Vous trouverez la dernière version de ce fichier sur l’exemple
Notes
Vous pouvez définir plusieurs environnements et en dupliquant les deployqa étape et en fournissant des paramètres différents. Si vous procédez de la sorte, assurez-vous que le nom de l’étape, le nom du travail, l’environnement cible et le nom du groupe variable sont uniques.
Notes
Vous pouvez déployer de façon conditionnelle dans différents environnements en utilisant des conditions
Configurer les informations d’identification pour les environnements
Les secrets ne doivent jamais être validés dans un référentiel pour des raisons de sécurité. Le pipeline décrit dans la procédure précédente utilise groupes de variables pour garder secrètes les valeurs de configuration. Les groupes de variables doivent être créés pour chaque environnement et le nom doit correspondre à ce qui est décrit dans la définition de pipeline (qa_configuration).
Pour créer le groupe variable, procédez comme suit :
- Connectez-vous à Azure DevOps, accédez à votre projet
- Sous Pipelines sélectionnez Bibliothèque
- Ajouter un nouveau Groupe variable en veillant à ce que le nom corresponde à ce qui est défini dans la définition du pipeline
- Ajoutez les variables suivantes au groupe et sélectionnez Enregistrer
- m365_user_login : connexion d’utilisateur d’un administrateur de clients SharePoint
- m365_user_password : mot de passe de l’utilisateur du compte
- m365_app_catalog_site_url : URL de la collection de sites du catalogue d’applications
Notes
Vous pouvez sélectionner l’icône cadenas en regard de l’entrée de valeur de la variable pour la marquer comme sensible et faire en sorte qu’Azure DevOps masque la valeur d’autres utilisateurs et des journaux.