Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’outil Solution Packager peut être utilisé avec n’importe quel système de contrôle de code source. Lorsqu’un fichier .zip de solution est extrait dans un dossier, ajoutez et envoyez les fichiers à votre système de contrôle de code source. Ces fichiers peuvent ensuite être synchronisés sur un autre ordinateur sur lequel ils peuvent être comprimés dans un nouveau fichier .zip de solution identique.
Un aspect important lors de l’utilisation des fichiers de composant extraits dans le contrôle de code source est que l’ajout de tous les fichiers dans le contrôle de code source peut entraîner une duplication inutile. Accédez à la Référence au fichier de composant de la solution pour connaître les fichiers générés pour chaque type de composant et les fichiers recommandés pour être utilisés dans le contrôle de code source.
Au fur et à mesure que d’autres personnalisations et modifications sont nécessaire pour la solution, les développeurs doivent modifier ou personnaliser les composants par d’autres moyens en place, effectuer une nouvelle exportation pour créer un fichier .zip, puis extraire le fichier de solution compressé dans le même dossier.
Important
À l’exception des sections décrites dans Quand modifier le fichier de personnalisations, la modification manuelle des fichiers de composant extraits et des fichiers .zip n’est pas prise en charge.
Lorsque l’outil Solution Packager extrait les fichiers de composant, il ne remplace pas les fichiers de composant existants du même nom si le contenu du fichier est identique. En outre, l’outil honore l’attribut en lecture seule des fichiers de composant en générant un avertissement dans la fenêtre de la console indiquant que des fichiers spécifiques n’ont pas été écrits. Cette protection permet à l’utilisateur d’extraire, du contrôle de code source, l’ensemble minimum de fichiers qui changent. Le paramètre /clobber permet de remplacer et d’entraîner l’écriture ou la suppression de fichiers en lecture seule. Le paramètre /allowWrite permet d’évaluer l’impact d’une opération d’extraction sans entraîner pour autant l’écriture ou la suppression de fichiers. L’utilisation du paramètre /allowWrite avec journalisation détaillée est effective.
Une fois l’opération d’extraction terminée avec l’ensemble minimal de fichiers extraits du contrôle de code source, un développeur peut renvoyer les fichiers modifiés dans le contrôle de code source, comme cela est fait avec tout autre type de fichier source.
Formats de fichier de contrôle de code source
L’outil Packager de solution prend en charge deux formats de fichiers pour les fichiers de composants extraits. Le choix du bon format avant évite d’avoir à migrer votre structure de référentiel ultérieurement.
| Format XML (hérité) | Format de contrôle de code source YAML | |
|---|---|---|
| Manifeste de solution | Other\Solution.xml + Other\Customizations.xml |
solutions/<name>/solution.yml et fichiers YAML associés |
| Lisibilité | XML détaillé | Compacter YAML : plus facile à lire et à réviser |
| Qualité des différences dans Git | Différences XML importantes | Différences minimales et ciblées |
| Référentiel multi-solution | Non pris en charge | Prise en charge : plusieurs solutions partagent un dossier |
| Les applications Canvas (.msapp) | Non pris en charge | Soutenu |
| Flux modernes | Non pris en charge | Soutenu |
| Intégration Git native | Non utilisé | Toujours utilisé : l’intégration Git écrit toujours YAML |
Quand utiliser le format YAML : Pour tous les nouveaux projets et chaque fois que vous utilisez l’intégration Git Dataverse native. Le format YAML est compatible avec les versions futures et produit un historique des modifications plus clair.
Quand utiliser le format XML : Uniquement lors de l’utilisation de référentiels existants qui utilisent déjà le format XML ou lors de l’utilisation d’outils hérités qui ne prennent pas en charge YAML.
Note
Lorsque vous validez des solutions à l'aide de l'intégration Git native dans Power Apps, elles sont toujours stockées au format de contrôle de code source YAML. Pour empaqueter ou décompresser manuellement cette source à l’aide de SolutionPackager ou pac solution pack, le dossier doit suivre la structure de dossiers YAML. Plus d’informations : Outil SolutionPackager — Formats de fichier de contrôle de code source
Développement en équipe
Lorsque plusieurs développeurs travaillent sur le même composant de solution, un conflit peut survenir lorsque des modifications apportées par deux développeurs entraînent des modifications dans un même fichier. Pour limiter l’occurrence de cette situation, décomposez chaque composant ou sous-composant modifiable individuellement dans un fichier distinct. Prenez en compte l’exemple suivant.
Les développeurs A et B travaillent tous les deux sur la même solution.
Sur des ordinateurs indépendants, ils obtiennent les dernières sources de la solution à partir du contrôle de code source, procèdent à l'empaquetage, puis importent un fichier .zip de solution non managée dans des organisations Microsoft Dataverse distinctes.
Développeur A personnalise la vue système « Contacts actifs » et le formulaire principal de l’entité Contact.
Le développeur B personnalise le formulaire principal pour l’entité Compte et modifie la « Vue de recherche de contacts ».
Les deux développeurs exportent un fichier .zip de solution non gérée et effectuent une extraction.
Le développeur A doit extraire un fichier pour le formulaire principal de Contact et un fichier pour la vue « Contacts actifs ».
Le développeur B devra vérifier un fichier pour le formulaire principal du compte, et un fichier pour la « Vue de recherche de contacts ».
Les deux développeurs peuvent envoyer, dans n’importe quel ordre, étant donné que leurs modifications respectives ont affecté des fichiers distincts.
Une fois les deux envois terminés, ils peuvent répéter l’étape n°2, puis continuer à apporter d’autres modifications dans leurs organisations indépendantes. Chacun dispose des deux ensembles de modifications, sans écraser son propre travail.
L’exemple précédent fonctionne uniquement lorsque des modifications sont apportées à des fichiers distincts. Il est inévitable que des personnalisations indépendantes nécessitent des modifications dans un seul fichier. En fonction de l’exemple présenté précédemment, considérez que le développeur B a personnalisé la vue « Contacts actifs » tandis que le développeur A l’a également personnalisé. Dans ce nouvel exemple, l’ordre des événements est essentiel. Le processus correct pour résoudre ce problème, dans le détail, est décrit ici.
Les développeurs A et B travaillent tous les deux sur la même solution.
Sur différents ordinateurs, ils accèdent tous les deux aux dernières sources de la solution à partir du contrôle de code source, compriment et importent un fichier .zip de solution non gérée dans des organisations indépendantes.
Développeur A personnalise la vue système « Contacts actifs » et le formulaire principal de la table Contact.
Le développeur B personnalise le formulaire principal pour la table de comptes et modifie les « Contacts actifs ».
Les deux développeurs exportent un fichier .zip de solution non gérée et effectuent une extraction.
Le développeur A doit effectuer un check-out d’un fichier pour le formulaire principal Contact, et d’un fichier pour la vue « Contacts actifs ».
Le développeur B doit extraire un fichier pour le formulaire principal du compte et un fichier pour la vue « Contacts actifs ».
Le développeur A est prêt en premier.
Avant d’envoyer ses modifications au contrôle de code source, le développeur A doit obtenir les sources les plus récentes pour garantir qu’aucune validation précédente n’entre en conflit avec ses modifications.
Il n’y a pas de conflit ; le développeur A peut donc effectuer son envoi.
Le développeur B est prêt après le développeur A.
Avant de soumettre, le développeur B doit s'assurer d'obtenir les sources les plus récentes pour garantir qu'aucune validation antérieure n'entre en conflit avec ses modifications.
Il existe un conflit, car le fichier pour « Contacts actifs » a été modifié depuis que le développeur B a récupéré les dernières sources.
Le développeur B doit résoudre le conflit. Il est possible que les fonctionnalités du système de contrôle de code source utilisé peuvent faciliter ce processus ; sinon, les options suivantes sont toutes viables.
Le développeur B, via l’historique du contrôle de code source, s’il est disponible, peut observer que le développeur A a effectué la modification précédente. Ils peuvent discuter de chaque modification en communication directe. Ensuite, seul le développeur B doit mettre à jour l’organisation avec la solution acceptée. Ensuite, le développeur B exporte, extrait et remplace le fichier conflictuel, puis l’envoie.
Autorisez le contrôle de code source à remplacer le fichier local. Le développeur B compresse la solution et l’importe dans son organisation, puis évalue l’état de la vue et la personnalise à nouveau selon les besoins. Ensuite, le développeur B peut exporter, extraire et remplacer le fichier en conflit.
Si la modification précédente est considérée comme inutile, le développeur B autorise la copie du fichier à remplacer la version dans le contrôle de code source et la soumet.
Que vous travailliez dans un environnement partagé ou un environnement indépendant, le développement en équipe de solutions Dataverse requiert que ceux qui travaillent activement sur une solution commune connaissent le travail des autres. L’outil Solution Packager n’élimine pas complètement cette nécessité, mais il permet la fusion facile des modifications non conflictuelles au niveau du contrôle de code source. De plus, il met en évidence de façon proactive les composants concis où des conflits se produisent.
Les sections suivantes sont les processus génériques pour utiliser efficacement l’outil Solution Packager dans le contrôle de code source lors du développement en équipes. Celles-ci fonctionnent aussi bien avec les environnements indépendants ou les environnements de développement partagés, bien qu’avec les environnements partagés, l’exportation et l’extraction incluent naturellement toutes les modifications présentes dans la solution, pas seulement celles effectuées par le développeur réalisant l’exportation. De même, lorsque vous importez un fichier .zip de solution, le comportement naturel de remplacer tous les composants se produit.
Créer une solution
Cette procédure identifie les étapes classiques utilisées lorsque vous créez une solution pour la première fois.
Dans un environnement propre avec Dataverse, créez une solution, puis ajoutez ou créez des composants selon vos besoins.
Lorsque vous êtes prêt à vous enregistrer, procédez comme suit.
Exportez la solution non gérée.
À l’aide de l’outil Solution Packager, extrayez la solution dans des fichiers de composants.
À partir de ces fichiers de composants extraits, ajoutez les fichiers requis dans le contrôle de code source.
Envoyez ces modifications au contrôle de code source.
Modifier une solution
La procédure suivante identifie les étapes standard utilisées lors de la modification d’une solution.
Effectuez une synchronisation ou obtenez les dernières sources de fichiers des composants de la solution.
À l’aide de l’outil Solution Packager, compressez les fichiers de composant dans un fichier .zip de solution non gérée.
Importez le fichier de la solution non gérée dans un environnement.
Personnalisez et modifiez la solution selon vos besoins.
Lorsque vous êtes prêt à vérifier les modifications dans le contrôle de code source, procédez comme suit.
Exportez la solution non gérée.
À l’aide de l’outil Solution Packager, extrayez la solution exportée dans les fichiers de composant.
Effectuez une synchronisation ou récupérez les dernières sources depuis le contrôle de code source.
En cas de conflit, résolvez-les.
Envoyez les modifications à la gestion de code source.
Les étapes 2 et 3 doivent être effectuées avant que d’autres personnalisations ne se produisent dans l’organisation de développement. À l’étape 5, l’étape b doit être effectuée avant l’étape c.
Voir aussi
Référence du fichier de composant de solution (SolutionPackager)
Outil SolutionPackager
Formats de fichier de contrôle de code source