Terug naar Dynamics 365 CE

Dynamics 365 Customer Engagement

CI/CD & ALM

Hoe een wijziging van de ontwikkelomgeving naar productie reist: geautomatiseerd, gecontroleerd en herhaalbaar.

Waarom CI/CD voor Dynamics 365

Een solution manueel exporteren en ergens anders importeren werkt tot de dag dat het niet meer werkt. Een pipeline maakt van elke release dezelfde release.

Herhaalbaar

Dezelfde stappen, in dezelfde volgorde, voor elke release en elke omgeving.

Traceerbaar

Elke deployment verwijst naar een commit, een work item en wie het goedkeurde.

Veilig

Kwaliteitscontroles en goedkeuringen houden problemen tegen voor ze productiegebruikers bereiken.

Snel

Kleine, frequente releases in plaats van een stresserende big bang elk kwartaal.

Een pipeline, fase per fase

Zo ziet een typische release-pipeline voor een Dynamics 365-solution eruit. Bekijk hoe ze loopt, of kies een fase om te zien wat daar gebeurt.

Commit

Een ontwikkelaar exporteert de unmanaged solution uit Dev, pakt ze uit tot bronbestanden en pusht een branch. Een pull request start de pipeline.

Pipeline-log
$ pac solution export --name ContosoCore --path out/ContosoCore.zip
$ pac solution unpack --zipfile out/ContosoCore.zip --folder src/ContosoCore --packagetype Both
$ git push origin feature/case-routing
✓ Pull request opened, pipeline triggered

Omgevingsstrategie

Een aanpak met meerdere omgevingen voor kwaliteitsborging:

DevUnmanaged
Build
Test
UAT
Production

De solution verandert één keer van vorm, in de build, en wordt verderop nooit manueel aangepast.

Unmanaged in ontwikkeling, managed overal elders

  • Ontwikkeling: Unmanaged solutions voor actieve ontwikkeling
  • Build/Integratie: Geautomatiseerde build- en testomgeving
  • Gebruikersacceptatietests (UAT): Validatie door de stakeholders
  • Productie: Managed solutions met change control
  • Sandbox: Omgevingen voor opleiding en experimenten

Solutionbeheer

  • Managed vs. unmanaged solutions: Een doordachte strategie voor solutionlagen
  • Solutionsegmentatie: Modulaire solutions die onafhankelijk uitgerold kunnen worden
  • Solutionpatches: Hotfixes en incrementele updates
  • Beheer van afhankelijkheden: Overzichtelijke afhankelijkheden en upgradepaden

Broncodebeheer en branching

De uitgepakte solution staat in Git naast de broncode van plugins en PCF, zodat elke wijziging wordt nagekeken zoals code.

mainfeature/case-routingfeature/sla-rulesv1.4v1.5
  • Kortlevende featurebranches, samengevoegd via pull requests met een verplichte build.
  • Eén uitgepakte solution per map, zodat diffs exact tonen welk formulier, welke weergave of flow wijzigde.
  • Versienummers gezet door de pipeline, nooit manueel.
  • Main is altijd uitrolbaar; releases krijgen een tag.

Een Azure DevOps-pipeline in YAML

Een ingekort voorbeeld met de Power Platform Build Tools. Echte pipelines voegen de plugin-build, tests en goedkeuringen per omgeving toe.

azure-pipelines.yml
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

De juiste tools kiezen

Build Tools en GitHub Actions zijn dezelfde Power Platform CLI-opdrachten in een andere verpakking; Pipelines in Power Platform is een ingebouwde Dataverse-dienst die u ook vanuit de CLI kunt starten. De keuze hangt af van waar uw team al werkt.

Pipelines in Power Platform

Ingebouwd in de maker-omgeving. Ideaal voor makers en kleinere teams die gecontroleerde deployments willen zonder een DevOps-platform te beheren. Let op: doelomgevingen moeten managed environments zijn, er is geen uitrol over tenants heen en elke solution heeft één ontwikkelomgeving.

Azure DevOps

Volledige controle met YAML-pipelines, Power Platform Build Tools, goedkeuringen, boards en testplannen op één plek.

GitHub Actions

Dezelfde mogelijkheden voor teams waarvan de code al op GitHub staat, met de Power Platform-actions van Microsoft.

CI/CD-automatisering

We zetten geautomatiseerde deploymentpipelines op met:

  • Azure DevOps: Build- en releasepipelines met Power Platform Build Tools
  • GitHub Actions: Git-gebaseerde workflows voor het uitrollen van solutions
  • Power Platform CLI: Automatisering via de opdrachtregel voor solutionbewerkingen
  • Solution Checker: Geautomatiseerde controle van codekwaliteit en best practices

Configuratie per omgeving

Een solution mag niets bevatten dat verschilt tussen omgevingen. Die waarden staan erbuiten:

  • Omgevingsvariabelen voor URL's, feature flags en instellingen.
  • Verbindingsverwijzingen, zodat flows de verbindingen van elke omgeving gebruiken.
  • Een bestand met deploymentinstellingen per omgeving, automatisch toegepast bij de import.
  • Geheimen in Azure Key Vault, waarnaar verwezen wordt in plaats van ze te kopiëren.

Geautomatiseerd testen

  • Unit tests voor plugins en custom API's, uitgevoerd in de build met een gesimuleerde Dataverse-context.
  • Solution Checker bij elke build, waarbij kritieke regels de pipeline laten falen.
  • UI-tests voor de processen die nooit mogen breken, uitgevoerd op Test na elke deployment.
  • Smoke tests na de deployment naar Productie, met het resultaat gepost in het teamkanaal.

Werkwijzen die releases saai houden

1

Rol uit met een service principal die als applicatiegebruiker is geregistreerd, nooit met een persoonlijk account.

2

Eén keer bouwen en hetzelfde artefact door elke omgeving promoveren.

3

Gebruik upgrades in plaats van updates wanneer componenten verdwijnen, zodat verwijderde onderdelen netjes wegvallen.

4

Laat geen unmanaged wijzigingen toe in Test of Productie; behandel ze als defecten.

5

Splits grote implementaties op in enkele solutions met duidelijke afhankelijkheden.

6

Genereer release notes uit de gekoppelde work items, zodat iedereen weet wat er veranderde.

VorigeIntegratiepatronenVolgendeCopilot & geavanceerde onderwerpen

Klaar om uw klantrelaties te transformeren?

Laten we bespreken hoe Dynamics 365 CE uw digitale transformatie kan ondersteunen. We helpen u graag bij het ontwerpen, bouwen en optimaliseren van uw Dynamics 365-oplossing.