Définir le modèle de dépôt
Microsoft fournit des recommandations dédiées pour X++ dans Git. Versionnez les sources et les métadonnées significatives en excluant les sorties de compilation, les caches locaux et les secrets.
Je privilégie un dépôt par produit ou solution cohérente, pas automatiquement un dépôt par modèle. Les modèles étroitement couplés doivent compiler et être livrés ensemble. À l'inverse, un monorepo contenant des clients et des produits sans rapport élargit le périmètre de build et encourage les dépendances accidentelles.
Ce qui appartient à Git
Versionner
- Descripteurs de modèle et de package (
.descriptor). - Métadonnées X++ et fichiers projet utiles (
.rnrproj). - Scripts de build et configuration NuGet.
- Tests automatisés et données de référence non sensibles.
- Documentation technique versionnée et ADR.
Exclure
- Binaires et sorties de build (
bin/,obj/). - Dossiers temporaires Visual Studio (
.vs/). - Packages téléchargés et cache NuGet.
- Clés, mots de passe et certificats (
.pfx,.snk). - Paramètres spécifiques à la VM développeur (
*.user).
.vs/
**/bin/
**/obj/
*.user
*.suo
PackagesLocalDirectory/bin/
PackagesLocalDirectory/XppMetadata/
*.pfx
*.snk
.env
# Expérience développeur unifiée — exclure les sorties générées
.pac/
OutputDirectory/Les chemins exacts diffèrent entre l'expérience classique et l'expérience développeur unifiée. Validez sur un clone propre : le pipeline peut-il restaurer, compiler et tester sans contenu local non déclaré ?
Choisir une stratégie de branches
Pour la plupart des équipes D365, le développement trunk-based avec des branches de courte durée est plus facile à gouverner que le GitFlow long. main reste stable et déployable ; chaque ticket utilise une branche temporaire qui ne dépasse pas la durée d'un sprint.
feature/ADO-1423-credit-controlefix/ADO-1510-ssrs-facturehotfix/ADO-1612-deadlock-batch
Les branches de release permanentes sont justifiées uniquement quand plusieurs versions supportées nécessitent vraiment une maintenance parallèle. Pour les déploiements SaaS, elles ne sont presque jamais nécessaires.
Créer des commits révvisables
Un commit doit exprimer une intention technique. Mélanger le renommage en masse, la mise en forme et la logique métier rend les revues XML inutilement risquées.
ADO-1423 Bloquer la commande client au-delà du plafond de crédit
- ajout de la classe de service QwoCreditPolicy
- wrapping de SalesTable.checkCreditLimit() via CoC
- couverture SysTest pour les clients bloqués et autorisés
- mise à jour de la version du descripteur de modèle à 1.1.0Le message lie le code au work item et explique l'intention. Les commits intermédiaires bruyants peuvent être squashés lors de la complétion de la pull request.
Résoudre les conflits de métadonnées X++ en sécurité
Les artefacts D365 sont des fichiers XML. Une fusion textuellement valide peut quand même créer un artefact invalide : contrôles dupliqués, références cassées ou propriétés supprimées. Le risque varie selon le type d'artefact :
| Type d'artefact | Risque de conflit | Approche de résolution sûre |
|---|---|---|
| Classe / méthode de table | Faible — les méthodes isolées entrent rarement en collision | Fusion standard ; compiler et tester |
| Formulaire (AxForm XML) | Élevé — arborescence de contrôles, sources de données et événements dans un seul fichier | Rouvrir dans le designer Visual Studio ; ne jamais fusionner le XML de formulaire manuellement |
| Descripteur de modèle | Moyen — version, liste de dépendances | Réconcilier manuellement les versions et la liste de dépendances |
| Fichier de labels | Moyen — lignes XML sensibles à l'ordre | Fusionner par ID de label ; supprimer les doublons ; recompiler les labels |
| Politique / rôle de sécurité | Élevé — la liste de privilèges peut perdre des entrées silencieusement | Recroiser la liste de privilèges d'origine après la fusion |
Après toute résolution de conflit de métadonnées : rouvrir l'objet dans Visual Studio, compiler le modèle et exécuter des tests ciblés. Ne résolvez pas un XML complexe uniquement dans un éditeur de texte.
Git dans l'expérience développeur unifiée
L'expérience développeur unifiée (développement local sur DevBox ou machine développeur, sans VM AOS complète) modifie certaines hypothèses Git :
- Les sources se trouvent dans un dossier
Reposmappé à une solution Power Platform ; le dépôt suit la même stratégie de branches, mais les chemins sousPackagesLocalDirectoryne s'appliquent plus. - Les métadonnées X++ sont compilées par la toolchain
pac d365 build, qui nécessite les packages NuGet et lenuget.configcorrects committés avec les sources. - Le dossier
.pac/et les sorties générées doivent être exclus de Git. - Les pull requests doivent toujours compiler depuis une image d'agent propre. Le guide CI/CD pour l'expérience développeur unifiée décrit le pipeline de référence.
Politique de pull request
- Un work item lié avec des critères d'acceptation lisibles.
- Au moins un relecteur familier avec le domaine impacté.
- Un build de validation obligatoire (compilation + Best Practice check au minimum).
- Les commentaires bloquants résolus, pas seulement accusés de réception.
- Preuves de test UI et SSRS attachées ou liées.
- Évaluation explicite des performances, de la sécurité et du traitement par lot pour toute méthode de table ou job batch.
- Aucun secret, binaire, fichier
.userni modification sans rapport. - Branche à jour avec
mainavant la fusion.
Contrôler les dépendances de modèles
Une dépendance ajoutée pour réutiliser une classe peut élargir le périmètre de compilation et imposer un ordre de déploiement. Challengez chaque nouvelle référence de package : la capacité peut-elle être exposée via une abstraction, un délégué, un contrat ou un modèle réellement partagé ?
Le pipeline doit compiler depuis un environnement propre. Un build qui réussit uniquement sur la VM de l'auteur expose généralement une dépendance locale non déclarée. Épinglez les versions de packages NuGet dans packages.config et committez le fichier.