Partager via

Utiliser le contrôle de code source avec les fichiers de solution

  • Article

 

Date de publication : novembre 2016

S’applique à : Dynamics CRM 2015

L’outil SolutionPackager peut être utilisé avec n’importe quel système de contrôle de code source. Lorsqu’un fichier .zip de solution a été extrait dans un dossier, ajoutez et envoyez simplement 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 point essentiel à prendre en considération lors de l’utilisation des fichiers de composants 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 réplication inutile. Voir Solution component file reference (SolutionPackager) pour connaître les fichiers générés pour chaque type de composant et les fichiers recommandés pour une utilisation 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

La modification manuelle des fichiers de composants extraits et des fichiers .zip n’est pas prise en charge.

Lorsque l’outil SolutionPackager extrait les fichiers de composants, il ne remplace pas les fichiers de composants du même nom si le contenu du fichier est identique. En outre, l’outil honore l’attribut lecture seule sur les fichiers de composants produisant un avertissement dans la fenêtre de la console indiquant que des fichiers spécifiques n’ont pas été écrits. Cela permet à l’utilisateur d’extraire, à partir 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 extrait du contrôle de code source, un développeur peut renvoyer les fichiers modifiés dans le contrôle de code source, comme avec tout autre type de fichier source.

Contenu de la rubrique

Développement en équipe

Créer une solution

Modifier une solution

Développement en équipe

Lorsque plusieurs développeurs travaillant sur le même composant de solution, un conflit peut survenir lorsque des modifications apportées par les 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.

  1. Les développeurs A et B travaillent tous les deux sur la même solution.

  2. 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 les organisations Microsoft Dynamics 365 indépendantes.

  3. Le développeur A personnalise la vue système « Contacts actifs » et le formulaire principal pour l’entité Contact.

  4. Le développeur B personnalise le formulaire principal pour l’entité Account et modifie la « Vue Recherche de contacts ».

  5. Les deux développeurs exportent un fichier .zip de solution non gérée et effectuent une extraction.

    1. Le développeur A doit extraire un fichier pour accéder au formulaire principal Contact, et un fichier pour la vue « Contacts actifs ».

    2. Le développeur B doit extraire un fichier pour accéder au formulaire principal Compte, et un fichier pour la « Vue Recherche de contacts ».

  6. Les deux développeurs peuvent envoyer leurs modifications dans n’importe quel ordre, étant donné que leurs modifications respectives concernent des fichiers distincts.

  7. 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 doivent apporter des modifications dans un seul fichier. Selon l’exemple indiqué ci-dessus, si le développeur B a personnalisé la vue « Contacts actifs » et que le développeur A l’a également personnalisée. Dans ce nouvel exemple, l’ordre des événements est essentiel. Le processus adéquat pour résoudre ce problème, dans le détail, est le suivant.

  1. Les développeurs A et B travaillent tous les deux sur la même solution.

  2. 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 les organisations indépendantes.

  3. Le développeur A personnalise la vue système « Contacts actifs » et le formulaire principal pour l’entité Contact.

  4. Le développeur B personnalise le formulaire principal pour l’entité Account et modifie la vue « Contacts actifs ».

  5. Les deux développeurs exportent une solution non gérée. Fichier et extrait zip.

    1. Le développeur A doit extraire un fichier pour accéder au formulaire principal Contact, et un fichier pour la vue « Contacts actifs ».

    2. Le développeur B doit extraire un fichier pour accéder au formulaire principal Compte, et un fichier pour la vue « Contacts actifs ».

  6. Le développeur est prêt en premier.

    1. Avant qu’il l’envoie au contrôle de code source, il doit obtenir les dernières sources pour s’assurer qu’il n’y a pas de conflit d’archivage antérieur avec ses modifications.

    2. Il n’y a pas de conflit ; il peut donc effectuer son envoi.

  7. Le développeur B est prêt après le développeur A.

    1. Avant qu’il l’envoie, il doit obtenir les dernières sources pour s’assurer qu’il n’y a pas de conflit d’archivage antérieur avec ses modifications.

    2. Il existe un conflit car le fichier des « Contacts actifs » a été modifié depuis la dernière fois qu’il a extrait les sources les plus récentes.

    3. 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é aident à ce processus ; sinon, les options suivantes sont toutes adéquates.

      1. Le développeur B, via l’historique de contrôle de code source, si disponible, peut voir que le développeur A a apporté la modification précédente. Ils peuvent discuter de chaque modification en discutant. Ensuite, seul le développeur B doit mettre à jour son organisation avec la solution acceptée. Ensuite, il exporte, extrait et remplace le fichier conflictuel, puis l’envoie.

      2. Autorisez le contrôle de code source à remplacer son 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 le cas échéant. Ensuite, il peut exporter, extraire et remplacer le fichier conflictuel.

      3. Si la modification précédente peut être considérée comme inutile, le développeur B autorise sa copie du fichier à remplacer la version dans contrôle de code source et l’envoie.

Que vous travailliez sur une organisation partagée ou des organisations indépendantes, le développement en équipe des solutions Microsoft Dynamics 365 requiert que les personnes qui travaillent activement sur une solution commune soient au courant du travail des autres. L’outil SolutionPackager ne supprime pas intégralement cette nécessité, mais il permet de fusionner plus facilement des modifications non contradictoires au niveau du contrôle de code source. De plus, il met en évidence les composants concis où des conflits sont apparus de façon proactive.

Les sections suivantes sont les processus génériques qui permettent d’utiliser efficacement l’outil SolutionPackager dans le contrôle de code source lors du développement en équipe. Elles s’appliquent aux organisations indépendantes comme aux organisations de développement partagées ; toutefois, pour les organisations partagées, l’exportation et l’extraction incluent toutes les modifications présentes dans la solution, pas seulement celles apportées par le développeur réalisant l’exportation. De même, lorsque vous importez un fichier .zip de solution, tous les composants sont remplacés.

Créer une solution

La procédure suivante identifie les étapes standard utilisées lors de la création d’une première solution.

  1. Dans une nouvelle organisation, créez une solution sur le serveur Microsoft Dynamics 365, puis ajoutez ou créez les composants selon vos besoins.

  2. Lorsque vous êtes prêt à archiver, procédez comme suit.

    1. Exportez la solution non gérée.

    2. Avec l’outil SolutionPackager, extrayez la solution dans les fichiers de composants.

    3. À partir de ces fichiers de composants extraits, ajoutez les fichiers requis dans le contrôle de code source.

    4. 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.

  1. Effectuez une synchronisation ou obtenez les dernières sources de fichier de composant de solution.

  2. Avec l’outil SolutionPackager, compressez les fichiers de composants dans un fichier .zip de solution non gérée.

  3. Importez le fichier de solution non gérée dans une organisation.

  4. Personnalisez et modifiez la solution selon vos besoins.

  5. Lorsque vous êtes prêt à archiver les modifications dans le contrôle de code source, procédez comme suit.

    1. Exportez la solution non gérée.

    2. Avec l’outil SolutionPackager, extrayez la solution exportée dans les fichiers de composants.

    3. Effectuez une synchronisation ou obtenez les dernières sources du contrôle de code source.

    4. En cas de conflit, résolvez-les.

    5. 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

Outils de solution pour le développement d’équipe
Solution component file reference (SolutionPackager)
Utiliser l’outil SolutionPackager pour compresser et extraire un fichier de solution

© 2017 Microsoft. Tous droits réservés. Copyright