CI/CD & ALM

Pourquoi le CI/CD pour Dynamics 365

Exporter une solution à la main pour l'importer ailleurs fonctionne jusqu'au jour où cela ne marche plus. Un pipeline fait de chaque livraison la même livraison.

Un pipeline, étape par étape

Voici la forme d'un pipeline de livraison typique pour une solution Dynamics 365. Regardez-le s'exécuter ou choisissez une étape pour voir ce qui s'y passe.

Stratégie d'environnement

Approche multi-environnements pour l'assurance qualité :

Gestion du code source et branches

La solution décompressée vit dans Git à côté du code des plugins et PCF, et chaque modification est relue comme du code.

• Des branches de fonctionnalité courtes, fusionnées par pull request avec un build obligatoire.
• Une solution décompressée par dossier, pour que les différences montrent exactement le formulaire, la vue ou le flux modifié.
• Les numéros de version sont fixés par le pipeline, jamais à la main.
• Main est toujours déployable ; les livraisons sont étiquetées.

Un pipeline Azure DevOps en YAML

Un exemple simplifié avec les Power Platform Build Tools. Les vrais pipelines ajoutent le build des plugins, les tests et les validations par environnement.

1trigger: 
2  branches: 
3    include: [ main ]
4 
5pool: 
6  vmImage: windows-latest
7 
8variables: 
9  SolutionName: ContosoCore
10 
11stages: 
12- stage: Build
13  jobs: 
14  - job: Pack
15    steps: 
16    - task: PowerPlatformToolInstaller@2
17    - task: PowerPlatformPackSolution@2
18      inputs: 
19        SolutionSourceFolder: src/$(SolutionName)
20        SolutionOutputFile: $(Build.ArtifactStagingDirectory)/$(SolutionName)_managed.zip
21        SolutionType: Managed
22    - task: PowerPlatformChecker@2
23      inputs: 
24        authenticationType: PowerPlatformSPN
25        PowerPlatformSPN: pp-build
26        FilesToAnalyze: $(Build.ArtifactStagingDirectory)/*.zip
27        RuleSet: 0ad12346-e108-40b8-a956-9a8f95ea18c9
28    - publish: $(Build.ArtifactStagingDirectory)
29      artifact: drop
30 
31- stage: DeployTest
32  dependsOn: Build
33  jobs: 
34  - deployment: Import
35    environment: Test
36    strategy: 
37      runOnce: 
38        deploy: 
39          steps: 
40          - checkout: self
41          - task: PowerPlatformToolInstaller@2
42          - task: PowerPlatformImportSolution@2
43            inputs: 
44              authenticationType: PowerPlatformSPN
45              PowerPlatformSPN: pp-test
46              SolutionInputFile: $(Pipeline.Workspace)/drop/$(SolutionName)_managed.zip
47              UseDeploymentSettingsFile: true
48              DeploymentSettingsFile: settings/test.json
49              HoldingSolution: true
50              AsyncOperation: true
51              MaxAsyncWaitTime: 60
52          - task: PowerPlatformApplySolutionUpgrade@2
53            inputs: 
54              authenticationType: PowerPlatformSPN
55              PowerPlatformSPN: pp-test
56              SolutionName: $(SolutionName)
57              AsyncOperation: true
58              MaxAsyncWaitTime: 60

Choisir les outils

Build Tools (v2) et les GitHub Actions sont les mêmes commandes PAC CLI dans des enveloppes différentes ; Pipelines dans Power Platform est un service Dataverse intégré que vous pouvez aussi déclencher depuis la CLI. Le choix dépend de l'endroit où votre équipe travaille déjà.

Automatisation CI/CD

Nous mettons en place des pipelines de déploiement automatisés avec :

• Azure DevOps : Pipelines de build et release avec les outils Power Platform
• GitHub Actions : Workflows basés sur Git pour le déploiement de solutions
• Power Platform CLI : Automatisation en ligne de commande pour les opérations de solutions
• Solution Checker : Validation automatique de la qualité du code et des bonnes pratiques