Concepts de création de branche

BranchManager for DOORS® supporte la création de plusieurs branches d'un projet dans DOORS®, en conservant les relations (liens et modules de liens) entre la structure complète des modules DOORS®. L'identification unique des exigences est maintenue à travers toutes les branches, permettant ainsi de visualiser l'historique à travers les branches sources et leurs enfants, ainsi que la fusion à travers les branches.

Comprendre les branches

La création d'une branche correspond à la copie d'un module DOORS® en conservant des références de ces copies. Les changements réalisés sur une copie peuvent être fusionnés avec une autre branche.
A partir de la version 9.5, il n'y a pas de concept naturel pour créer une branche dans DOORS®.
A noter que la création de branche est faite au niveau d'un module, c'est-à-dire que durant la création de la branche, une copie d'un module formel est créée (à voir aussi Qu'est ce que BranchManager for DOORS® copie?). Dans la suite de la documentation, on appelle le module d'origine et les modules copiés des 'modules parallèles'.

Afin d'être cohérent avec DOORS®, BranchManager for DOORS® défini une branche comme étant un projet DOORS®. Dans ce projet, il ne peut pas y avoir de modules parallèles, c'est-à-dire que lorsque l'on fait une branche d'un module, la cible doit être dans un autre projet DOORS®. Lorsque l'on fait une comparaison ou une fusion de module, seulement la branche cible (projet) aura besoin d'être sélectionnée. BranchManager for DOORS cherchera le module automatiquement. BranchManager for DOORS® inclus des données dans les modules copiés pendant la création de la branche. Ces données sont conservées sous la forme d'un module spécifique et d'attributs sur les objets qui permettent d'identifier le module à partir duquel la branche a été réalisée et les fusions qui ont été faites pour chaque objet.

Lorsque l'on créé une branche pour un module DOORS®, BranchManager for DOORS® fait une copie de tous les objets et attributs du module (avec quelques exceptions) vers le module cible. Les objets conservent leur hiérarchie (dans le module) et leur identifiant unique. En fonction du cas d'utilisation pour la création de la branche, il peut être intéressant de donner au module cible un préfixe différent (afin d'avoir des identifiants d'objets différents) dans les deux branches. Comme pour les modules, les objets copiés sont appelés ‘objets parallèles’ dans cette documentation.

BranchManager for DOORS® copie aussi les liens sortants du module DOORS® copié. Pour avoir des détails sur le traitement des liens, veuillez consulter le chapitre sur le Traitement des liens. Les liens entrants, en cohérence avec ce que propose DOORS®, ne font pas partie du module source et ne seront pas copiés (voir aussi Création incrémentale d'une branche et Traitement des liens pendant la création d'une branche.

Traitement des liens pendant la création d'une branche

Comment BranchManager for DOORS® copie les liens

Lors de la création d'une branche, il est important que tous les liens du module copié existent aussi dans la branche cible. Cependant, dans certains cas, lorsque les liens ne peuvent pass être créés dans la branche cible, quand par exemple l'objet cible a été supprimé, ou le module cible n'existe pas, cela doit être géré d'une autre façon. C'est pour cela que BranchManager for DOORS® fournit deux options qui vont définir comment gérer le traitement des liens dans ces cas.

Lors de la création d'une branche, BranchManager for DOORS® va essayer de récopier les liens sortants des modules formels copiés de la manière suivante (A noter que dans les exemples suivants, cela importe peu si les modules A et B sont dans le même projet):
Si les modules sources et cibles des liens sont tous les deux copiés, le lien sera re-copié dans la branche cible. Ce cas sera toujours assuré puisque BranchManager for DOORS® vient de créer les deux modules dans la branche cible.


Link_Branch_Normal.png

Si seulement le module source est copié, mais qu'il existe déjà un module parallèle dans la branche, et qu'il y a aussi un objet parallèle pour le lien cible, alors BranchManager for DOORS® va re-copier le lien dans la branche cible. En utilisant cette stratégie, une hiérarchie de modules peut copier un couple de modules en même temps, pourvu que la création de branche soit réalisée du haut de la hiérarchie vers le bas (voir aussi Création d'une branche incrémentale).

Link_Branch_Exist.png

S'il n'y a pas de module parallèle pour la cible du lien dans la branche cible, alors BranchManager for DOORS® recréera le lien si l'option “Recréer les liens version les projets distants” est sélectionnée. Dans ce cas, le lien sera créé vers le même objet cible que le lien d'origine. Sinon, le lien sera ignoré et un message d'information sera renvoyé à la fin de la création de la branche.

Link Handling - Branch Target exists outside

S'il y a un module parallèle pour la cible du lien dans la branche cible, mais que dans ce module l'objet parallèle n'existe pas (par exemple il n'a pas encore été fusionné, ou alors il a été supprimé) alors BranchManager for DOORS® recréera le lien vers la cible d'origine seulement si l'option “Rediriger les liens des objets qui sont manquants dans la branche cible vers les objets de la branche source” est sélectionnée. Sinon le lien sera ignoré et un message d'information sera renvoyé à la fin de la création de la branche.

Link_Branch_Not_Exist.png

Comment BranchManager for DOORS® traite les modules de liens

En général, les modules de liens sont valides à l'intérieur du projet, où se situent les liens. Donc, lorsque BranchManager for DOORS® copie un lien ou un ensemble de liens d'un module DOORS®, il vérifiera si le module de lien correspondant est situé dans le même projet que le module source. Dans ce cas, BranchManager for DOORS® fera aussi une copie du module de lien. Si un module utilise un module de lien en dehors de son projet, alors ce module de lien sera ré-utilisé, c'est-à-dire que les liens et les ensembles de liens de la branche cible utiliseront le même module de liens.

Link Module Handling

Comment BranchManager for DOORS® traite les options sur les liens

Lors de la création d'une branche, BranchManager for DOORS® copiera les restrictions sur les liens du module source. De cette façon, dans le cas nominal, l'utilisateur sera capable d'éditer dans la branche juste après la copie, sans avoir à changer l'organisation des liens dans la branche. Les modules cibles et les modules de liens sont réactualisés en fonction de la disponibilité des modules cibles et de liens dans la branche cible.

Cependant, dans certains cas, comme faire une copie de deux modules d'un projet conséquent vers un espace de travail privé, cela pourrait conduire vers le résultat non désiré de liens dans les modules cibles, qui pointent vers des modules dans le projet source, encore accessible dans la branche cible (Voir aussi Traitement des liens). Dans ce cas, BranchManager for DOORS® a une option qui "autorise seulement les liens à l'intérieur de la branche cible". Cette option permettra seulement la création des ensembles de liens pour les modules copiés, qui ont leur module cible dans la branche. Dans le schéma suivant, les liens vers branche source sont encore là, mais ils ne sont pas éditables.

Sandbox Branching

Stratégies de création de branche

Création de branche incrémentale

Les branches peuvent être créées de manière incrémentale afin de gérer la taille et le temps de création. Comme décrit dans le chapitre Traitement des liens pendant la création d'une branche, BranchManager for DOORS® créera les liens vers les modules qui existent dans la branche cible. Ceci peut être utilisé pour créer une branche d'un nouveau module à partir d'une branche source vers d'autres branches, par exemple pour mettre à jour une branche de résolution de bugs avec de nouveaux modules. Lorsque la branche entière est réalisée, il n'est pas nécessaire de se préoccuper de l'ordre puisque BranchManager for DOORS® fera en sorte de créer les modules dans le bon ordre.

La création de branche incrémentale commence par le haut de la hiérarchie puis descend vers le bas. Les modules liens cibles font soit partie de l'opération de création de branche, ou existent déjà dans la branche cible.

Incremental Branching

Gestion de la hiérarchie des dossiers

Lors de la création d'une branche, la branche recopiera la hiérarchie des dossiers, qu'il y ait un ou plusieurs modules à migrer. Si l'utilisateur décide de restructurer la branche, il n'y a pas de limitation et les relations avec la branche source restent les mêmes. Lorsque deux branches ont des structures de dossiers différentes, il faut faire attention lorsque l'on veut créer une branche pour de nouveaux modules à partir d'une branche vers l'autre. BranchManager for DOORS® créera les modules dans leur structure d'origine, ensuite ces modules doivent être bougés manuellement vers l'endroit désiré de la nouvelle branche. A noter que l'historique du module ne prendra pas en compte la modification manuelle, puisque BranchManager for DOORS® ne prend pas en compte les changements sur les dossiers. Cela n'affectera pas les fonctionnalités mais doit être gardé en mémoire afin d'éviter des confusions lorsque l'on retrace l'historique du module. Pour la même raison, il n'est pas recommandé de bouger un module formel vers une branche différente. Bien que cela n'affectera pas les fonctionnalités de l'outil, cela pourrait créer de la confusion lorsque les utilisateurs visualisent l'historique de la branche du module.

Gestion des liens

Quelques points importants doivent être pris en compte lorsque l'on crée une branche:


Pour répondre à la première question, deux stratégies peuvent être suivies. Imaginons un gros projet avec quatre modules A, B, C et D. Le module A a des liens vers un module M de niveau supérieur. La première façon de créer une branche est de copier seulement les modules A, B, C et D. Dans ce cas, puisque le lien cible du module A (module M) n'est pas dans la branche, les liens sortants sont créés normalement de la branche source (si l'option "Recréer les liens vers les projets distants" est active pendant la création de la branche). De cette façon, pour éditer les liens sortants du module A, les utilisateurs devront travailler avec les modules de la branche source.
Comme alternative, le module M peut aussi être copié dans la branche et l'option "Recréer les liens vers les projets distants" peut être désactivée. De cette façon, les deux branches restent indépendantes. Le module M peut être protégé en écriture et non fusionné vers la branche source. Il sert seulement comme cible des liens.

Link_Management

Historique des branches

Comprendre l'historique des branches

L'historique de branches d'un module contient:

Imaginons un module à partir duquel deux branches ont été créées, à partir d'une source appelée 'Branch A' vers 'Branch B' et à partir de 'Branch B' vers 'Branch C', comme sur la figure suivante:

Understand History Module View

Le version de référence 1.1 de ce module est copiée vers la branche B, puis deux autres versions de références sont créées, avant de créer la branche C. L'historique du module de la branche C contient l'historique du module de la branche B jusqu'à la version de référence 2.0 et l'historique du module dans la branche A jusqu'à la version 1.1. Il n'est pas important si la version de référence 2.0 de la branche branch A ou la version de référence 3.0 de la branche B existe au moment de la création de la branche ou non. Dans l'historique du module C, seules les versions de références ayant contribuées à l'état courant du module apparaîtrons.

Puisque chaque version de référence est un point naturel pour les modules formels, ces versions de référence apparaîtront dans l'historique de branche des modules.

Understanding History Timeline

Le module source 'ne sait pas' que des branches ont été créées à partir de lui. L'historique du module dans la branche A ne renverra pas les opérations de création de branche. Il n'y aura pas de modification de faites sur le module de la branche A pendant la création de la branche. Par conséquent, les branches B et C peuvent être supprimées plus tard sans conséquence négative.

La base commune

La base commune de deux modules est la version de référence que les deux modules parallèles partagent. Imaginons l'historique de branche suivant:

Common Base

La version commune pour le module de la branche C et le module de la branche B est la version de référence 1.1 de la branche A, puisque c'est la dernière version de référence que les deux modules ont en commun dans leur historique. Après cette version de référence, leur historique diverge, c'est-à-dire qu'entre la version de référence 1.1 et la version de référence 2.0 de la branche A il y a des changements sur le module de la branche A, qui n'appraissent pas dans l'historique de la branche B.
Cela montre que la base commune de deux modules n'est pas nécessairement une version de référence de chaque module. Puisque la base commune est importante pour l'intégration de deux modules, il faut garder en tête que:

Une version de référence d'un module qui est une base commune de deux branches ne devrait pas être supprimée de la base de données, ainsi que le module lui-même.

Il vaut mieux déplacer le module de la branche A dans un dossier archive quelque part dans la base de données. De cette façon le script d'intégration sera toujours capable de trouver le module. Si la base commune de deux branches est accidentellement supprimée, alors l'intégration n'est plus possible. Dans ce cas, vous devrez contacter le support BranchManager for DOORS®.

Détails techniques

Qu'est-ce que BranchManager for DOORS® copie?

Pendant la création de branche, BranchManager for DOORS® copie:

Différences entre un module formel et un module copié

Bien que la création de branche fait une copie complète du module source, quelques différences entre le module source et sa copie peuvent être observées:

Méta donnée des attributs

Pendant la copie, BranchManager for DOORS® créé des attributs dans les nouveaux modules. Ces attributs contiennent des méta données pour le module, l'historique de l'objet et des attributs références utilisés pour identifier les modules parallèles, ainsi que les objets. Les attributs suivants sont créés pendant la copie:

Nom de l'attribut Périmètre Description
BranchManager Internal ID Module Cet attribut de module contient une copie de la base de données contenant les modules, ainsi que l'identifiant du module. Il est nécessaire lors de la détection de la copie, au niveau du module.
Format:   <db-ID>:<mod-ID> où
<db-ID> est l'identifiant de la base
<mod-ID> est l'identifiant du module
BranchManager Internal Reference Long Module + Objet L'attribut "BranchManager Internal Reference Long" , au niveau module, contient une référence vers la branche racine (i.e. le plus vieil ancêtre - le module qui a été copié en premier dans l'historique du module) et l'ancêtre immédiat du module (qui est le module à partir duquel la branche a été créée)
Format: <db-root>:<mod-root>::<db-ancestor>:<mod-ancestor>où
<db-root> est l'identifiant de la base dans la branche racine
<mod-root> est l'identifiant du module dans la branche racine
<db-ancestor> est l'identifiant de la base de l'ancêtre immédiat
<mod-ancestor> est l'identifiant du module de l'ancêtre immédiat

L'attribut "BranchManager Internal Reference Long", au niveau objet, contient une référence vers la branche racine de l'objet (i.e. le plus vieil ancêtre - l'objet qui a été copié en premier dans l'historique de l'objet) et une référence vers l'objet lui-même (utilisé pour la détection des copies):
Format: <db-root>:<mod-root>:<abs-root>::<db-this>:<mod-this>:<obj-this> où
<db-root> est l'identifiant de la base de l'objet racine de la branche
<mod-root> est l'identifiant du module de l'objet de la branche racine (leading zeros stripped)
<abs-root> est l'Absolute Number de l'objet racine de la branche
<db-this> est l'identifiant de la base courante
<mod-this> est l'identifiant du module courant (leading zeros stripped)
<abs-this> est l'Absolute Number de l'objet courant
BranchManager Branch History Module + Objet L'attribut "BranchManager Branch History" est une entrée qui décrit l'historique de branche pour les objets et modules.

Format pour un module:
|INTBS|<date>|<reason>|<srcFullName>|<tgtFullName>|<srcID>|<srcBaseline>|<tgtID>|<tgtBaseline>
où:
<date> est la date (i.e. date/heure de la version de référence) en utilisant le format:  yyyy-MM-dd hh:mm:ss
<reason> est le type, i.e.  "Integration-Baseline", "Branch" ou "Baseline"
<src<reason>|<srcID>|<srcBaseline>|<srcObject>|<tgtID>|<date>|FullName> le nom complet de la source de l'intégration, ou la source de la branche ou le nom complet du module au moment de la version de référence
<tgtFullName> le nom complet de la cible de l'intégration, ou de la cible du module au moment de la version de référence d'intégration (<n/a> en cas de "version de référence")
<srcID> l'ID du module ou de la source de l'intégration, ou de la source de la branche ou du module qui a été versionné
<srcBaseline> la version de référence de la source de l'intégration, ou de la source de la branche ou du module qui a été versionné
<tgtID> l'ID du module ou de la source de l'intégration, ou de la source de la branche (<n/a> en cas de "version de référence") 
<tgtBaseline> la version de référence de la source de l'intégration, ou de la source de la branche (en cas de "version de référence")

Format pour un objet:
|HIST|<reason>|<srcID>|<srcBaseline>|<srcObject>|<tgtID>|<date>|  
ou:
<reason> la raison de l'entrée i.e.. "Branch" ou "Merge"
<srcID> L'ID du module source à partir duquel les objets viennent
<srcBaseline> La version de référence du module à partir duquel le module vient.
<srcObject> L'Absolute Number de l'objet source
<tgtID> L'ID du module cible
<date> est un entier représentant la date et l'heure
BranchManager Current Integration Module L'attribut est vide s'il n'y a pas eu d'intégration sur le module. S'il y a eu une intégration, l'attribut stocke les paramètres de l'intégration tel que:
|INT|<srcID>|<srcBase>|<tgtID>|<tgtBase>|
où:
<srcID>, <scrBase>, <tgtID>,<tgtBase> sont les identifiants du module source, de la base source, du module cible, de la base cible, dans le format: id[(suffixe major.minor)] où id est l'identifiant du module et [(suffixe major.minor )] est la version de référence (mis de côté en cas de version courante).
BranchManager Last Integrated On Objet Cet attribut est vide au démarrage d'une intégration et stocke la date et l'heure de la dernière opération "Marqué comme intégré" / Fusion. De cette façon, le script de fusion peut reconnaître que l'objet source de l'intégration a changé après que l'objet ait été fustionné (dans le cas où le module source est une version courante). Si c'est le cas, l'objet apparaîtra dans l'interface d'intégration. 
BranchManager Integration/Merge Changes Objet Cet attribut est vide au démarrage d'une intégration et enregistre toutes les opérations de fusion. Il peut être utilisé pour filtrer les objets ayant déjà été fusionnés dans l'intégration courante.
BranchManager Integration Options Module Cet attribut stocke les paramètres d'intégration. Format:
<deleted>|<structure>|<attributes>|<link>|<attribute 1>|<attribute 2>|...|<attribute n>
où:
<deleted> vrai ou faux, doit être pris en compte dans le cas d'objet nouveau ou supprimé
<structure> vrai ou faux, doit être pris en compte dans le cas d'un changement de hiérarchie
<link> vrai ou faux, doit être pris en compte en cas de changement sur un lien
<attribute x> le nom des attributs qui doivent être intégrés.

Conseils sur les performances

La création d'une branche est une opération gourmande en ressource: