Note
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 documenté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.
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 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 Microsoft Dataverse indépendantes.
Le développeur A personnalise la vue système « Contacts actifs » et le formulaire principal pour 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 accéder au formulaire principal Contact, et un fichier pour la vue « Contacts actifs ».
Le développeur B doit extraire un fichier pour accéder au formulaire principal 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 d’eux dispose d’ensembles de modifications, mais n’écrase pas leurs travaux respectifs.
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. Sur la base de l’exemple indiqué 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ée. 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.
Le développeur A personnalise la vue système « Contacts actifs » et le formulaire principal pour la table Contact.
Le développeur B personnalise le formulaire principal pour la table Compte et modifie la vue « 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 extraire un fichier pour accéder au formulaire principal Contact, et un fichier pour la vue « Contacts actifs ».
Le développeur B doit extraire un fichier pour accéder au formulaire principal Compte, et un fichier pour la vue « Contacts actifs ».
Le développeur A est prêt en premier.
Avant d’envoyer au contrôle de code source, le développeur A doit obtenir les sources de données les plus récentes pour garantir qu’aucun archivage précédent 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 d’envoyer, le développeur B doit obtenir les sources de données les plus récentes pour garantir qu’aucun archivage précédent n’entre en conflit avec ses modifications.
Il existe un conflit car le fichier pour « Contacts actifs » a été modifié depuis la dernière récupération des sources les plus récentes par le développeur B.
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 discutant. 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 l’envoie.
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 à archiver, 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.
À 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 fichier de composant de 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 obtenez les dernières sources du contrôle de code source.
En cas de conflit, résolvez-les.
Envoyez les modifications au contrôle 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