L'intégration avec BranchManager for DOORS®

BranchManager for DOORS permet la fusion de branches, en détectant les changements dans les contenus, structure et emplacement des objects correspondants. L'intégration est réalisée en utilisant une fusion de type "three-way" en misant sur une base commune. La base commune peut être soit le parent commun de la branche ou un point d'intégration précédent pour les deux branches. Les changements non conflictuels (pas de changement sur le même object dans les deux branches) peuvent être automatiquement fusionnés. Les changements conflictuels nécessitent des choix de l'utilisateur.

Comprendre les fusions

Dans BranchManager for DOORS®, une fusion définit le processus de "transfert" des changements d'un module dans une branche vers le même module, dans une branche différente. Cette section décrit le concept de fusion dans BranchManager for DOORS®.

Fusion "Three-Way" (Intégration) et conflits

BranchManager for DOORS® implémente une fusion "three-way" pour tenir compte de la détection des conflits.

Three-Way-Merge

La figure ci-dessus montre la situation générale pour une fusion de type "three-way": deux modules, qui ont une base commune (voir Historique des branches), c'est-à-dire qu'à un moment donné, les deux modules ont été identiques (après la création de branche). A partir de ce point, des changements ont été appliqués aux deux modules. Ces changements peuvent être conflictuels, ce qui signifie que le même objet du côté source a été changé d'une façon, et du côté cible, d'une autre façon.  Exemple:

Lors de la création de branche
(Base communce)
Côté source Côté cible
Object Text The unit shall have a red button. The control unit shall have a red button. The unit shall have a red  push button labeled with a solid red circle with 5mm diameter

Dans l'exemple ci-dessus, le text de l'exigence, du côté source, a été changé de manière différente par rapport au côté cible. Il est impossible de savoir pour BranchManager for DOORS® si le changement côté source s'applique du côté cible et de quelle façon cela peut être intégré. Même si les changements sont sur des attributs différents, BranchManager for DOORS® ne peut pas savoir si ces deux changements sont compatibles:

Lors de la création de branche
(Base commune)
Côté source Côté cible
Object Text
The weight of the unit must not exceed 5kg.  The weight of the unit must not exceed 5kg.  The weight of the unit must not exceed 5kg 4kg.
Review Comment In work In workAccepted In work

Les deux changements, dans la table ci-dessus, bien que pas sur le même attribut, peuvent être en conflit. Peut être que le commentaire "Accepted" ne s'applique plus si le poids passe de 5kg à 4kg. C'est la même chose pour les liens et les attributs. Un nouveau lien peut ne pas être satisfait lorsque le text de l'exigence change. C'est pour cette raison que BranchManager for DOORS® considère les cas suivants comme conflictuels:


Changement sur un atttribut Changement sur un lien Mouvement
Changement sur un attribut Conflit Conflit
Changement sur un lien Conflit Conflit
Mouvement

Conflit

La table ci-dessus montre qu'un mouvement n'est pas en conflit avec un changement sur un attribut ou un changement sur un lien. Cela s'applique a beaucoup de cas, puisque la position d'une exigence dans un document ne devrait pas être dépendante de son contenu.

Intégration itérative, l'intégration de base et les conflits

Lorsque deux branches, créées à partir d'un même produit, existent en parallèle, plusieurs intégrations seront réalisées dans le temps. BranchManager for DOORS® supporte ce scénario en s'assurant que chaque changement réalisés du côté source, doit être révisé seulement une fois, et donc fusionné ou non. L'image suivante montre la situation:

Repeated Merges: Each change must be reviewed only once

La branche B est créée à partir de la branche A. Dans les deux modules, une version de référence est créée, cela marque la base commune pour les deux branches. Ensuite, les changements sont appliqués des deux côtés. Lorsque la première intégration est réalisée, il peut y avoir des conflits à cause de changements dans la branche A. Lorsque l'intégration est terminée, BranchManager for DOORS® force la création d'une version de référence pour les deux branches. De cette façon, pour une deuxième intégration, seuls les changements qui ont été réalisés sur la branche B après la première intégration seront pris en compte. La version de référence qui a été créée avec la première intégration sert maintenant de base d'intégration pour la seconde intégration.

Bien que ce soit efficace lors de la fusion, cela entraîne une autre complication: Lors que la première intégration, chaque changements dans la branche B peut être fusionné ou pas. Après la deuxième intégration, les modules ne seront pas identiques. Cela laisse BranchManager for DOORS® avec la situation suivante après la deuxième intégration:

Four-Way-Merge

Puisque la base source et la base cible sont différentes, un changement peut être fait sur un objet source alors qu'il n'a pas été changé dans la cible, mais dans ce cas la base source et la base cible sont différentes. Dans BranchManager for DOORS® on appelle cela un conflit de base (base-conflict) et c'est une source en plus pour des conflits. Exemple:



Côté source Côté cible
Après la création de branche The weight of the unit must not exceed 5kg.  The weight of the unit must not exceed 5kg. 

Côté source Côté cible
Premier changement The weight of the unit must not exceed 5kg 4kg. The weight of the unit must not exceed 5kg. 


Côté source Côté cible
Première version d'intégration
The weight of the unit must not exceed 4kg.  The weight of the unit must not exceed 5kg.
Note: Dans l'intégration ci-dessus le changement n'a pas été fusionné de l'autre côté.

Côté source Côté cible
Deuxième changement The weight of the control  unit including cables to the actuator must not exceed 4kg.  The weight of the unit must not exceed 5kg.
Note:Bien qu'il n'y a pas eu de changement du côté cible, le changement ne peut pas être intégré, puisque que la base source (version d'intégration de la première intégration) et la base cible sont différentes. 

Comme on peut le voir dans l'exemple ci-dessus, le deuxième changement ne peut pas être intégré vers la cible, tant que le premier changement n'a pas été intégré. Dans ce cas, l'utilisateur doit décider si la cible doit recevoir le changement ou pas. Eventuellement, l'utilisateur aura à résoudre le conflit manuellement pour l'exigence: The weight of the control unit including cables to the actuator must not exceed 5kg.

Comprendre les fusions et les conflits

Dans la section précédente, on a vu que BranchManager for DOORS® peut résoudre les conflits de changement et les conflits de base. Malheurement, ce ne sont pas les seuls conflits qui peuvent arriver pendant une fusion. Puisque BranchManager for DOORS® fonctionne sur des modules DOORS, qui consiste en une hiérarchie d'objets, liés éventuellement à d'autres modèles, deux autres problèmes peuvent arriver lorsque l'on tente de fusionner des changements d'un module source vers un module cible.

Lorsque l'on essaie, par exemple, de fusionner des changements de hiérarchie réalisés en créant, supprimant ou bougeant des objets DOORS du côté source, BranchManager ne peut pas automatiquement et dans tous les cas fusionner un changement du côté cible. Exemple:

Conflict due to Hierarchy Creation

Dans l'image ci-dessus, du côté source, il y avait une hiérarchie impliquant deux nouveaux objets, object 5 et object 6 - object 5 étant le parent de object 6. A partir de l'image on peut constater que l'object 6 ne peut pas être fusionné avant que l'object 5 ne le soit. Donc les deux changements sont dépendants et doivent être fusionnés dans le bon ordre. Un autre exemple:

Merge Conflict due to deletion

Dans l'image ci-dessus, un nouvel objet (5) a été créé du côté source, mais l'objet parent du côté cible (2) est supprimé. Puisqu'il n'est pas possible de créer un objet sous un objet supprimé, le changement ne peut pas être fusionné. DOORS a un modèle de données complexe, il existe donc d'autres cas où BranchManager for DOORS® échouerait lors d'une tentative de fusion. Voici une liste des plus évidents:
Dans les cas ci-dessus, BranchManager for DOORS® ne sera pas tout le temps capable de détecter les conditions à l'avance, l'utilisateur pourrait avoir un message d'erreur de BranchManager for DOORS® indiquant que l'opération de fusion à échoué.

Comment BranchManager for DOORS® traite les liens pendant la fusion

La comparaison et la fusion des liens est un problème complexe, spécialement lorsque des liens et des scénarios complexes sont considérés. Comme décrit dans la section compare, l'intégration et la fusion rapide autoriseront l'utilisateur à fusionner soit les créations de liens, soit les suppressions de liens dans le module cible. Pour cela, BranchManager for DOORS® doit décider
a) quelle est la bonne version du module cible
b) quel est le bon objet cible
c) quel module de lien utiliser pour créer le lien

Voici les réponses à ces questions:

Quels module et version de référence seront utilisés?

Si un changement de lien est détecté sur la source, BranchManager for DOORS® vérifiera tout d'abord si le lien pointe sur un module dans la branche source (cible du lien interne) ou vers un lien en dehors de la branche source (cible du lien externe). Si le lien pointe vers une cible externe, alors le même module sera considéré comme cible pour le lien fusionné. Si le lien pointe vers une cible interne, alors BranchManager for DOORS® essaiera de localiser le module cible dans la branche cible. Si le module n'existe pas, alors le changement sur le lien ne peut pas être fusionné. Comme décrit dans la section compare, la version de référence à utiliser comme cible sera déterminée en vérifiant vers quelle version de référence la plupart des liens dans le module cible pointent. S'il n'y a pas de lien, alors la version courante du module sera utilisée comme cible.
Link Merges

Quel est le bon objet cible?

Le bon objet se trouve dans le module cible. Pour un module interne, les objets sont mis en correspondance par le Branch Reference Identifier. Pour un module externe, l'objet avec le même Absolute Number est utilisé. A noter que la branche source et la branche cible peuvent utiliser des versions de référence différentes d'une cible externe pour le lien. Si l'objet correspondant n'existe pas dans la cible du lien, alors le changement ne peut pas être fusionné.

Quel module de lien utiliser pour créer un lien?

BranchManager for DOORS® autorise chaque branche à avoir une configuration de liens séparée. Par conséquent, BranchManager for DOORS® utilisera le module de lien configuré par le module cible comme étant le module de lien utilisé par les liens. Si l'ajout de lien vers ce module n'est pas autorisé, alors la fusion du lien créé échouera. Dans ce cas, l'utilisateur doit adapter la configuration afin d'autoriser les liens vers le module cible. BranchManager for DOORS® n'adaptera pas automatiquement la configuration de lien pour la même raison que BranchManager for DOORS® ne crée pas d'attributs ou ne fait pas de changements dans le modèle de données des modules. BranchManager for DOORS® assume que la synchronisation des configurations et du modèle de données des deux modules est planifiée.

Changements équivalents et changements qui ne seront pas considérés pour une fusion

BranchManager for DOORS® a été créé afin d'être capable de travailler avec des variants. Un aspect important des variants est que l'ensemble des chapitres des documents pourrait être applicable pour une branche. Dans ce cas, on peut assumer que si le chapitre X est seulement applicable au variant A et non pas pour le variant B, alors les changements dans le chapitre X, pour le variant A ne seront pas montrer dans l'intégration si:
Logiquement, lorsqu'un chapitre X a été créé du côté source et qu'une intégration a été réalisée, quelqu'un a décidé de ne pas fusionner le chapitre X du côté cible, ou quelqu'un a décidé de supprimer le chapitre X après qu'il ait été copié du côté cible (création d'une branche). BranchManager for DOORS® assume que dans ce cas, n'importe quel changement sur ces objets n'a pas d'importance du côté cible. Si ces objets doivent être fusionnés du côté cible plus tard, alors l'utilisateur peut commencer une intégration qui revient vers la base commune, et ainsi l'autorisera à fusionner la création des objets.

Le deuxième cas pour lequel un changement ne sera pas visualisé par l'interface d'intégration est lorsque le même changement a été manuellement appliqué dans la cible, c'est-à-dire que les objets source et cible sont égaux. Dans ce cas, il n'y a rien à fusionner, par conséquent le changement ne sera pas visible dans l'interface de fusion. Ceci est utile, spécialement lorsque les changements sont fusionnés manuellement ou si la fusion rapide est utilisée pour fusionner les changements. A noter cependant que si un autre changement est fait du côté source, après qu'un autre changement ait été fusionné, BranchManager for DOORS® verra un conflit puisque la cible est différente du côté source et que les deux côtés ont été changés.

Comprendre la fusion rapide (two-way-merge)

two-way-merge

La fusion rapide (two-way-merge) fonctionne en comparant directement deux modules l'un par rapport à l'autre. Pour cela, BranchManager for DOORS® fournit l'outil de fusion rapide. Cela signifie qu'aucune détection de conflit n'est possible. Il n'y a pas de base commune de prise en compte, et donc il ne peut pas être déterminé si le module source ou le module cible a été changé, seulement qu'il y a une différence. La fusion rapide montre toujours toutes les différences entre les modules. Fusionner deux objets en utilisant la fusion rapide signifie les rendre égaux (au moins tous les types de changements sélectionner pour faire la comparaison).

A noter que la fusion rapide (two-way-merge) est un cas spécial de l'intégration (three-way-merge), si pour la base source et la base cible le module cible est choisit. En fait, BranchManager for DOORS® traite la fusion rapide en utilisant le même algorithme que pour l'intégration (three-way-merge). La figure suivante le démontre:

Two-Way vs. Three Way merge

Puisque du côté cible, le module cible est utilisé comme base cible et module cible, il n'y a pas de différence qui pourrait conduire à un conflit. Aussi si pour les modules de base, le module cible est utilisé, alors il n'y a pas de différence de base. Du côté source, le module cible est utilisé comme base source (avant changement). Done les changements qui sont montrés considèrent le module source comme module plus récent que le module cible.

Utiliser efficacement la fusion rapide et l'intégration

La fusion rapide du BranchManager for DOORS® est un cas d'utilisation différent que l'intégration. La première différence est que l'intégration "pousse" les modifications. Ce qui signifie que l'utilisateur travaille à partir de la source et transfère les objets vers une ou plusieurs branches cibles. Puisque les deux laissent l'utilisateur choisir si les attributs, liens ou structures des éléments doivent être fusionnés ou non, il paraît intéressant d'utiliser l'intégration pour un certain type de changements et d'utiliser la fusion rapide pour un autre type de changements.

Si par exemple on veut s'assurer que les liens dans les deux branches sont synchronisés, alors on peut utiliser la fusion rapide pour synchroniser les liens entre les branches, alors que l'intégration sera utilisée pour synchoniser les objets et les attributs. On peut aussi vouloir garder synchrones les attributs entre les branches, on pourra dans ce cas utiliser la fusion rapide sur ces attributs en particulier.

Dans tous les cas, on doit considérer quels sont les attributs à fusionner entre deux branches. Les attributs de processus, comme les attributs de revue, peuvent ne pas être souhaités pour une fusion, alors que les exigences du processus pourrait forcer une revue séparée dans les deux branches. Pour cela, BranchManager for DOORS® autorise la configuration d'attributs communs, qui sont pré-sélectionnés dans les vues de fusion et de comparaison.

Méta-données de fusion

Pendant une fusion, BranchManager for DOORS® crée un couple d'attributs afin de conserver les méta-données de l'intégration / fusion rapide. Cela est nécessaire afin de pouvoir reprendre l'intégration à un autre moment. Pour les attributs créés, veuillez vous référer à la section Méta-données des attributs de la page Création d'une branche.