Synchroniser des objets agiles GitLab dans Squash TM

Principe

Une fois le plugin Xsquash4GitLab configuré correctement, les issues GitLab sont automatiquement synchronisées en tant qu'exigences dans Squash TM et sont maintenues à jour. À la première mise à jour, le répertoire de synchronisation ainsi que l'ensemble des exigences synchronisées contenues dans ce répertoire sont créés.

La synchronisation se fait uniquement dans le sens GitLab vers Squash TM.

Cette partie détaille l’organisation de ce patrimoine dans l’espace Exigences.

Les exigences synchronisées

Affichage

Les issues GitLab sont représentées dans Squash TM par des exigences synchronisées. Ces exigences apparaissent avec un nom en grisé dans l’arborescence des exigences et sont précédées d'une icône .

Cette icône indique non seulement qu'il s'agit d'une exigence synchronisée mais elle donne également des informations sur le statut de synchronisation de l'issue GitLab associée via le code couleur suivant :

• icône verte : l'exigence est toujours mise à jour par synchronisation
• icône jaune : l'exigence n'est plus mise à jour par synchronisation car l'issue GitLab correspondante n'entre plus dans le périmètre de synchronisation défini au niveau de la configuration du plugin (par exemple, pour une synchronisation dont le filtre correspond à un label, l'issue GitLab n'est plus associée à ce label)
• icône rouge : l'exigence n'est plus mise à jour par synchronisation car l'issue GitLab correspondante a été supprimée dans GitLab
• icône noire : le statut de synchronisation de l'issue est inconnu (par exemple, lorsque la synchronisation globale est en échec)

De plus, les exigences synchronisées disposent de trois informations supplémentaires par rapport aux exigences natives :

• Un lien hypertexte vers l'issue GitLab d’origine
• Le statut de synchronisation de l'issue GitLab qui indique si l'exigence est toujours mise à jour par synchronisation et si l'issue GitLab correspondante est toujours présente dans GitLab
• Le statut de la synchronisation à laquelle appartient l'issue GitLab, qui permet d’alerter l’utilisateur si la communication entre Squash TM et GitLab est rompue ou qu’une erreur est survenue lors du dernier process de mise à jour

Modification, déplacement et suppression

Les exigences synchronisées peuvent être modifiées dans Squash TM. Il y a deux cas de figure selon le champ modifié :

• il s'agit d'un champ synchronisé (par exemple : description, référence, ou tout autre champ pour lequel une équivalence est renseignée) : les modifications apportées seront écrasées lors d'une prochaine synchronisation dès que l'issue GitLab sera mise à jour
• il s'agit d'un champ non synchronisé : les modifications seront conservées dans Squash TM

Attention

Les statuts 'Approuvé' et 'Obsolète' bloquent toutes modifications sur une exigence. Ainsi, lorsqu'une exigence synchronisée passe à l'un de ces statuts, elle n'est plus mise à jour par synchronisation. Il faudra modifier le statut manuellement à 'En cours de rédaction' ou 'À approuver' pour réactiver la mise à jour de l'exigence.

Les exigences synchronisées peuvent être déplacées dans l'arborescence des exigences. À nouveau, plusieurs cas de figure :

• les exigences sont déplacées au sein du même projet : elles sont toujours mises à jour et restent ou non à leur nouvel emplacement selon le type de synchronisation (voir Organisation des exigences synchronisées)
• les exigences sont déplacées dans un autre projet : elles deviennent des exigences natives dans le projet de destination et seront recrées à la prochaine synchronisation dans le projet d'origine

À la suppression d'exigences synchronisées dans Squash TM :

• si les exigences sont toujours dans le périmètre de synchronisation : elles seront recrées à la prochaine synchronisation
• si les exigences ne sont plus dans le périmètre de synchronisation : elles ne seront pas recréées dans Squash TM

Hiérarchies hybrides

Il est tout à fait possible d’ajouter une sous hiérarchie d’exigences natives en tant que sous hiérarchie d’une exigence synchronisée.
Par exemple, une issue donnée dans GitLab pourrait nécessiter plusieurs exigences de test dans Squash TM. Ces exigences de test sont à créer sous l’exigence synchronisée qui représente cette issue dans Squash TM.

Ainsi, le reporting dans GitLab prendra en compte toute la hiérarchie d’exigences et tous les cas de test qui lui sont liés.

Le répertoire cible

Le répertoire cible correspond au répertoire parent dans lequel sont synchronisées les issues GitLab. Selon le type de synchronisation, des répertoires peuvent être créés automatiquement sous le répertoire cible.

Statut de la synchronisation

Les répertoires et sous-répertoires cibles sont précédés d'une icône et adoptent un code couleur similaire aux exigences synchronisées :

• icône verte : la synchronisation correspondant au répertoire cible est en succès et toutes les exigences synchronisées qu'il contient sont mises à jour par synchronisation
• icône jaune : la synchronisation correspondant au répertoire cible est en succès mais il contient des exigences qui ne sont plus mises à jour par synchronisation parce qu'elles sont sorties du périmètre de synchronisation ou parce qu'elles n'existent plus dans GitLab
• icône rouge : la synchronisation correspondant au répertoire cible est en échec (par exemple, lorsque la communication entre Squash TM et GitLab est rompue ou qu’une erreur est survenue lors du dernier process de mise à jour)

Déplacement et suppression

Les répertoires cibles peuvent être déplacés dans l'arborescence des exigences :

• les répertoires cibles sont déplacés au sein du même projet : les exigences qu'ils contiennent sont toujours mises à jour
• les répertoires cibles sont déplacés dans un autre projet : les exigences qu'ils contiennent deviennent des exigences natives dans le projet de destination et les répertoires cibles seront recréés à la prochaine synchronisation dans le projet d'origine

Si les répertoires cibles sont supprimés dans Squash TM, ils seront recréés à la prochaine synchronisation.

Organisation des exigences synchronisées

Lors de l'ajout d'une synchronisation, plusieurs modes d'organisation des exigences synchronisées sont proposés selon le type de synchronisation (par issue ou par board). Selon l'organisation choisie, Xsquash4GitLab crée automatiquement des répertoires sous le répertoire cible dans l'arborescence des exigences.

A plat

Ce mode d'organisation est disponible uniquement pour les synchronisations de type "Issue".

Avec l'organisation "A plat", les exigences sont créées à la racine du répertoire cible. L’utilisateur est ensuite libre d’organiser les exigences synchronisées comme il le souhaite, tant qu’il ne les change pas de projet afin qu'elles soient toujours mises à jour.

Par iteration et par milestone

Ces deux modes d'organisation sont disponibles pour les synchronisations de type "Issue" et "Board".

Avec les organisations "Par iteration" et "Par milestone", les iterations et milestones sont représentés sous forme de dossiers dans l'arborescence des exigences et contiennent les exigences synchronisées qui correspondent aux issues associées à cette iteration ou à ce milestone dans GitLab.
Les issues associées à aucune iteration ou aucun milestone se trouvent quant à eux à la racine du répertoire cible.

Focus

Pour les synchronisations dont le périmètre est un projet GitLab :

• un dossier est créé pour chaque milestone du projet et du sous-groupe et du groupe
• un dossier est créé pour chaque iteration du sous-groupe et du groupe

Pour les synchronisations dont le périmètre est un groupe GitLab :

• un dossier est créé pour chaque milestone du groupe et de ses sous-groupes et de ses projets
• un dossier est créé pour chaque iteration du groupe et de ses sous-groupes

Si une issue change d'iteration ou de milestone dans GitLab ou n'est plus associée à une iteration ou un milestone, elle est déplacée automatiquement dans Squash TM dans le dossier correspondant.

Focus

L’accumulation d'iterations et de milestones terminés dans GitLab entraîne la création de nombreux répertoires correspondant dans Squash TM. Pour améliorer la lisibilité, il est possible de créer un (ou plusieurs) répertoires d’archive à la racine du répertoire cible et d’y déplacer les iterations et milestones terminés. À l’intérieur de ce répertoire d’archive, il est possible de s’organiser en sous-répertoire par année, par thème ou toute autre forme d’organisation qui conviendra.

Si l’organisation en iteration ou milestone n’a plus de sens, il est possible de déplacer les exigences synchronisées n’importe où dans le même projet Squash. La seule restriction est de ne pas supprimer les anciens répertoires d'iteration et de milestone, sinon ils seront recréés lors de la prochaine mise à jour.

Attention

Il est conseillé de ne pas déplacer les dossiers d'iteration et de milestone non terminés, ni leur contenu. Une fois l'iteration ou le milestone terminés et les issues GitLab fermées, l’archivage dans Squash est libre.

Par arborescence

Ce mode d'organisation est disponible uniquement pour les synchronisations de type "Issue".
Il est surtout pertinent lorsque le périmètre de synchronisation est un groupe GitLab.

Avec l'organisation "Par arborescence", les sous-groupes et projets GitLab du groupe synchronisé sont représentés sous forme de hiérarchie de dossiers dans l'arborescence des exigences. Chaque dossier "Projet" contient les exigences synchronisées qui correspondent aux issues du projet GitLab.

Si l’organisation par arborescence n’a plus de sens, il est possible de déplacer les exigences synchronisées n’importe où dans le même projet Squash. La seule restriction est de ne pas supprimer les anciens répertoires du projet, sinon ils seront recréés lors de la prochaine mise à jour.