Aide de l'utilisateur > Regroupement d'unités de travail dans des lots de modifications > Vue d'ensemble de la commande Resynchroniser le lot de modifications > Utilisation d'un lot de propagation avec Resynchroniser le lot de modifications
  
Utilisation d'un lot de propagation avec Resynchroniser le lot de modifications
Vous pouvez utiliser un autre lot de modifications pour enregistrer toutes les modifications de membre effectuées par une opération Resynchroniser le lot de modifications. Le lot de modifications utilisé à cet effet est appelé un lot de propagation.
* 
Même si votre administrateur a défini les lots de modifications comme obligatoires, il est inutile de spécifier un lot de propagation pour une opération Resynchroniser le lot de modifications.
Vous ne créez pas un lot de propagation. Vous créez un lot de modifications normal et les informations de propagation sont enregistrées dans le lot de modifications lorsque vous le spécifiez lors de l'opération Resynchroniser le lot de modifications. Pour isoler au mieux les modifications, il est recommandé de démarrer avec un lot de propagation vide. Si le lot de propagation ne contient aucune entrée, les seuls ajouts seront ceux qui concernent spécifiquement les modifications en question.
Le lot de propagation répertorie toutes les modifications de membre et de sous-projet effectuées, ainsi que les lots de modifications propagés suite à la resynchronisation. Vous pouvez ignorer les modifications de membre indésirables et ajouter des conflits de fusion résolus dans le lot de propagation. Vous pouvez également ajouter les entrées requises au lot de propagation à l'aide de commandes Windchill RV&S, par exemple, Récupérer, Déplacer, Renommer, Mettre à jour la révision actuelle ou Créer un sous-projet.
Une fois que toutes les modifications sont terminées, le lot de propagation peut être soumis pour mettre à jour le projet.
* 
Vous pouvez également soumettre le lot de propagation sans mettre à jour les révisions actuelles. Le buildmaster applique alors le lot de propagation au moment où le logiciel est généré.
Les entrées dans le lot de propagation remplacent les entrées correspondantes dans les lots de modifications resynchronisés. Par conséquent, si vous effectuez une fusion à partir d'une branche et intégrez les résultats dans un lot de propagation, la révision qui en résulte remplace toutes les entrées dans les lots de modifications répertoriés qui pourraient être sur des branches.
Avantages de l'utilisation d'un lot de propagation
L'utilisation d'un lot de propagation permet de s'assurer que les autres développeurs peuvent appliquer le même jeu de lots de modifications sans avoir à répéter l'exécution de la commande Resynchroniser le lot de modifications et à résoudre les erreurs ou des conflits de fusion.
Les lots de propagation sont également utiles pour aider les buildmasters à terminer leur travail. Lorsqu'une opération Appliquer le lot de modifications échoue, les développeurs peuvent utiliser la commande Resynchroniser le lot de modifications sur le même lot de modifications, identifier les dépendances et les fusions requises et inclure toutes les modifications nécessaires dans un même lot de propagation.
Les lots de propagation permettent de propager les modifications par paliers entre les chemins de développement en utilisant à plusieurs reprises la commande Resynchroniser le lot de modifications pour récupérer les modifications de projet plutôt qu'en effectuant une seule grande opération de resynchronisation qui pourrait prendre du temps.
Si vous utilisez un lot de propagation, les lots de modifications dont dépend le lot de modifications appliqué, ayant déjà été appliqués au projet via une opération Resynchroniser le lot de modifications, n'apparaissent pas dans la liste de comblement. Vous recevez un message d'avertissement concernant les lots de modifications qui ont déjà été appliqués.
Il est à noter que bien qu'il soit possible d'utiliser la commande Resynchroniser le lot de modifications pour appliquer un lot de propagation, les résultats ne seront pas toujours acceptables. Par exemple, si votre correctif de bogue se trouve dans un membre de projet existant, le projet doit déjà contenir une archive de ce membre. Par conséquent, Resynchroniser le lot de modifications ajouterait le membre modifié sur une branche. Cette ramification supplémentaire n'est peut-être pas acceptable dans votre projet.
Exemple d'utilisation d'un lot de propagation
La société abcBusiness a deux équipes de développement :
Une équipe produit qui développe le logiciel et les nouvelles fonctions pour le cycle de version principal.
Une équipe de développement de maintenance qui entretient le logiciel publié et corrige les bogues identifiés par les clients.
L'équipe produit (EP) implémente les nouvelles fonctions et créations sur le chemin de développement principal.
L'équipe de développement de maintenance (EDM) travaille sur un chemin de développement variant de la version 2.0 et résout les problèmes dans le produit récemment lancé. L'objectif principal de cette équipe est de créer des correctifs de bogues pour la version 2.0a. Le processus de travail pour l'EDM est :
Un bogue est signalé par un client.
Un lot de modifications est créé pour le bogue, ici avec l'ID de conteneur 1204. Les processus sont activés et un élément est créé puis associé à un lot de modifications créé.
Un développeur EDM est affecté à la résolution du problème.
Le développeur EDM crée un lot de modifications.
Il apporte les modifications nécessaires et teste le code.
Il réintègre les fichiers modifiés dans le projet variant, en veillant à associer les fichiers au lot de modifications 1204:1.
Dans ce cas de figure, tout le travail du développeur EDM est maintenant intégré au chemin de développement variant et fera partie de la version 2.0a. Cependant, le travail de correction de bogue de l'EDM doit être à nouveau transféré dans le chemin de développement principal pour être intégré à la nouvelle version du produit. Un développeur EP doit récupérer les modifications de correction du bogue et les appliquer dans une sandbox. La commande Resynchroniser le lot de modifications constitue la meilleure option d'application du nouveau correctif.
Le développeur EP crée un deuxième lot de modifications, 1204:2, pour le même élément. Le deuxième lot de modifications inclut le résumé "Correctif appliqué au chemin de développement principal". Le développeur EP démarre la commande Resynchroniser le lot de modifications et sélectionne la sandbox de développement principale et le premier lot de modifications (1204:1) dans cet élément. Le deuxième lot de modifications (1204:2) est utilisé comme lot de propagation.
Une fois que tous les conflits de fusion ont été résolus, le développeur soumet le lot de propagation et Windchill RV&S applique les modifications dans les lots de modifications référencés.
Le correctif de bogue est désormais effectif dans chaque chemin de développement, principal et variant, garantissant ainsi la résolution du problème dans la version 2.0a et la version majeure suivante du produit.