Pipeline YAML Azure DevOps pour D365 F&O : du commit à l'artefact déployable

Choisir le bon modèle de pipeline

Le flux classique utilise les outils de build Finance and Operations et les packages NuGet pour créer un package déployable LCS. L'expérience développeur unifiée compile X++ via pac d365 build et produit un package Power Platform unifié. Voir Automatisation de build avec des agents hébergés Microsoft et CI/CD pour l'expérience développeur unifiée.

Conception recommandée des étapes

1. Valider : conventions, détection de secrets, structure des métadonnées et graphe de dépendances.
2. Restaurer : packages NuGet et outils de build à des versions épinglées.
3. Compiler : modèles X++, labels et rapports SSRS avec politique warnings-as-errors.
4. Tester : tests unitaires (SysTest) et vérifications d'intégrité du package.
5. Packager : génération de l'artefact immuable avec tampon de version.
6. Publier : manifest, checksum SHA-256, logs et package vers le feed d'artefact.
7. Déployer : promotion protégée vers chaque environnement avec pré-vérifications et approbations.

Configuration NuGet et épinglage de baseline

La configuration NuGet est le fichier le plus important pour la reproductibilité du build. Une référence de version flottante peut modifier la sortie de compilation entre deux commits sources identiques.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="D365-Platform"
         value="https://pkgs.dev.azure.com/{org}/{project}/_packaging/D365-Packages/nuget/v3/index.json" />
    <add key="Interne"
         value="https://pkgs.dev.azure.com/{org}/{project}/_packaging/Internal/nuget/v3/index.json" />
  </packageSources>
</configuration>

# packages.config — épingler chaque version explicitement
Microsoft.Dynamics.AX.Platform.DevALM.BuildXpp          7.0.7279.57
Microsoft.Dynamics.AX.Application.DevALM.BuildXpp       10.0.2135.37
Microsoft.Dynamics.AX.ApplicationSuite.DevALM.BuildXpp  10.0.2135.37

Committez nuget.config et packages.config à la racine du dépôt. La version de baseline doit correspondre à la version de l'application cible. Un décalage est détecté à la compilation mais coûte des minutes de build quand il est découvert tard.

Squelette YAML lisible

trigger:
  branches:
    include: [ main ]

pr:
  branches:
    include: [ main ]

variables:
- group: d365-build-non-secret
- name: artifactName
  value: d365-package
- name: baselineVersion
  value: '10.0.48'

stages:
- stage: Valider
  jobs:
  - job: Metadata
    pool:
      vmImage: windows-latest
    steps:
    - checkout: self
      clean: true
    - template: templates/validate-metadata.yml

- stage: Build
  dependsOn: Valider
  jobs:
  - job: CompilerEtPackager
    pool:
      vmImage: windows-latest
    timeoutInMinutes: 120
    steps:
    - template: templates/restore-d365.yml
      parameters:
        baselineVersion: $(baselineVersion)
    - template: templates/compile-xpp.yml
    - template: templates/run-systests.yml
    - template: templates/create-package.yml
      parameters:
        artifactName: $(artifactName)
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: $(artifactName)

- stage: Deploy_UAT
  dependsOn: Build
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: Promouvoir
    environment: D365-UAT
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: $(artifactName)
          - template: templates/deploy-lcs.yml
            parameters:
              environment: UAT

Bibliothèque de templates de pipeline

Organisez les étapes réutilisables dans un dossier templates/ committé dans le même dépôt :

templates/
├── validate-metadata.yml    # Vérifications descripteur, scan de secrets
├── restore-d365.yml         # Restauration NuGet avec paramètre de version
├── compile-xpp.yml          # Invoke-D365ModuleCompile / xppc
├── run-systests.yml         # Invoke-D365ModuleTestsInAzure / test runner
├── create-package.yml       # Create-D365Deployable / génération du manifest
├── deploy-lcs.yml           # Invoke-D365LcsAssetUpload + Invoke-D365LcsDeployment
└── notify-teams.yml         # Notification webhook Teams en cas d'échec

Versionnage des modèles et des artefacts

Baseline applicative : 10.0.48
Train de release      : 2026.07
Révision de build     : 8421
Nom de l'artefact     : QWO-D365-10.0.48-2026.07.8421.zip
Commit                : 7c4e90a

manifest.json :
{
  "baseline":   "10.0.48",
  "release":    "2026.07",
  "buildId":    8421,
  "commit":     "7c4e90a",
  "branch":     "refs/heads/main",
  "modeles":    ["QwoCore", "QwoIntegration", "QwoReporting"],
  "workItems":  ["ADO-1423", "ADO-1510", "ADO-1577"],
  "sha256":     "e3b0c44298fc1c149afbf4c8996fb924...",
  "builtUtc":   "2026-07-22T18:34:00Z"
}

Le manifest est stocké avec le ZIP dans le feed d'artefact. Tout consommateur aval peut reconstruire la chaîne de provenance complète à partir du seul nom de l'artefact.

Portes de qualité

• Compilation complète de tous les modèles de la solution, pas uniquement du projet modifié.
• Avertissements Best Practice critiques et bloquants traités comme des erreurs.
• Suite SysTest ciblée à chaque build ; suite de régression élargie planifiée.
• Détection de secrets et de binaires inattendus dans le dépôt.
• Validation des métadonnées et du graphe de dépendances de modèles.
• Seuil de taille du package avec comparaison au build réussi précédent.

Secrets et identités

Utilisez les connexions de service Azure DevOps, les groupes de variables liés à Key Vault et les environnements protégés. Attribuez aux identités l'accès minimal requis aux feeds, aux stores d'artefacts et aux environnements cibles. Masquez les tokens au niveau du groupe de variables et ne publiez jamais le contenu de configuration sensible dans les journaux de build.

Déploiement et approbations

• Un environnement Azure DevOps par cible de déploiement (UAT, Pré-Prod, Prod).
• Chaque environnement définit des pré-vérifications automatisées et des approbateurs nommés.
• Téléchargez par identifiant d'artefact immuable et version — jamais « latest ».
• Enregistrez le résultat du déploiement (succès/rollback/abandon) dans un work item de release lié.

Liste de contrôle Tech Lead

1. Le YAML est-il versionné dans Git et protégé par une politique de PR ?
2. La version de baseline et les dépendances NuGet sont-elles explicitement épinglées ?
3. Chaque build démarre-t-il depuis un workspace propre (clean: true) ?
4. Le package déployable est-il généré exactement une fois et jamais reconstruit ?
5. Le manifest et le checksum SHA-256 sont-ils publiés avec l'artefact ?
6. Les secrets utilisent-ils des groupes de variables Key Vault ou des connexions de service ?
7. Chaque environnement applique-t-il des approbations nommées et des pré-vérifications automatisées ?
8. L'ensemble des preuves de release peut-il être reconstitué à partir du seul nom de l'artefact ?

Voir aussi

• Déployer un package D365 F&O via LCS — ce qui se passe après la publication de l'artefact par le pipeline
• Git et X++ — la stratégie de branches qui alimente le déclencheur du pipeline
• Structurer un backlog Azure DevOps pour un programme D365 — lier les builds du pipeline aux work items et aux releases

Références Microsoft Learn

• Automatisation de build avec des agents hébergés Microsoft
• CI/CD pour l'expérience développeur unifiée
• Déployer des artefacts LCS via Azure Pipelines
• d365fo.tools — module PowerShell open source