Synchroniser des Milestones ou Itérations GitLab dans l'espace Exécutions de Squash TM

Principe

Si une synchronisation de sprints Xsquash4GitLab est configurée, les sprints GitLab sont automatiquement synchronisés dans l'espace Exécutions de Squash TM et sont maintenus à jour. À la première mise à jour, le chemin configuré (répertoires et groupe de sprints) ainsi que l'ensemble des sprints synchronisés sont créés.

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

Info

Seuls la création et le contenu (tickets) des sprints sont impactés par la synchronisation. Pour le reste, y compris la validation des tickets, la gestion des sprints synchronisés est identique à celle des sprints manuels.

Cette partie détaille l'organisation des sprints dans l'espace Exécutions.

Pour l'organisation dans l'espace Exigences, consulter la page Synchroniser des exigences.

Les sprints synchronisés

Affichage

Les éléments GitLab (itérations ou milestones, selon la configuration de synchronisation) sont représentés dans Squash TM par des sprints synchronisés. Ces sprints apparaissent dans l'arborescence des exécutions et sont précédées d'une icône (, , ou selon le statut).

A l'intérieur de ces sprints se trouvent des tickets de sprint, qui correspondent aux issues GitLab de l'itération ou milestone concerné (ne sont synchronisés que les issues incluses dans le périmètre déterminé dans la configuration de la synchronisation).

Attention

Il est impossible d'ajouter manuellement des exigences à un sprint synchronisé car c'est le périmètre de la synchronisation qui détermine les tickets du sprint concerné.

Dans l'arborescence, l'icône indique non seulement qu'il s'agit d'un sprint synchronisé mais elle donne également des informations sur le statut de synchronisation de l'élément GitLab associé :

• flèches vertes : le sprint est toujours mis à jour par synchronisation ;
• flèches jaunes : le sprint est partiellement mis à jour par synchronisation : une ou plusieures issues GitLab de ce sprint ne sont plus synchronisés (par exemple, l'issue GitLab a été déplacée dans un autre milestone) ;
• flèches rouges : le processus de mise à jour a échoué, aucun élément n'est mis à jour ;
• cadenas : l'élément a été fermé sur GitLab depuis la dernière synchronisation. Ce sprint et son contenu ne seront pas mis à jour lors des processus de mise à jour tant que celui-ci sera fermé (en cas de réouverture de l'élément dans GitLab, s'il entre à nouveau dans le périmètre, alors il sera resynchronisé) ;
• corbeille : l'élément a été supprimé côté GitLab depuis la dernière synchronisation. Ce sprint et son contenu ne seront plus mis à jour lors des processus de mise à jour suivants.

Info

Les icônes cadenas et corbeille dans l'arborescence permettent de visualiser l'état des sprints qui ne sont pas synchronisés avec GitLab, sans avoir à consulter les détails de celui-ci.

État des sprints synchronisés

Les sprints synchronisés disposent d'une information supplémentaire par rapport aux sprint manuels :

• L'état du sprint dans GitLab dans l'ancre Informations du sprint synchronisé.

L'État GitLab est synchronisé et c'est lui qui détermine si les tickets doivent être synchronisés :

• À venir / Ouvert / Expiré : le sprint et ses tickets sont synchronisés ;
• Fermé / Supprimé : le sprint et ses tickets ne sont pas synchronisés.

Pour les autres actions du sprint, notamment celles liés au test, c'est l'État Squash qui doit être utilisé.

Modification, déplacement et suppression

Les sprints synchronisés peuvent être déplacés dans l'arborescence des exécutions. Il y a plusieurs cas de figure :

• ils sont déplacés au sein du même projet : ils seront toujours mis à jour et resteront à leur nouvel emplacement ;
• ils sont déplacés dans un autre projet : ils deviennent des sprints manuels dans le projet de destination et seront recréés à la prochaine synchronisation dans le projet d'origine (s'ils font toujours partie du périmètre synchronisé).

À la suppression de sprints synchronisés dans Squash TM :

• si les sprints sont toujours dans le périmètre de synchronisation : ils seront recréés au prochain processus de mise à jour ;
• si les sprints ne sont plus dans le périmètre de synchronisation : ils ne seront pas recréés dans Squash TM.

Tickets d'un sprint synchronisé

Généralités

Un ticket de sprint synchronisé correspond à une issue GitLab paramétrée pour la synchronisation. En plus du nom, les principaux attributs du ticket sont synchronisés avec les valeurs présentes dans GitLab (id, catégorie, criticité, statut et description qui contient les pièces-jointes sous forme de liens).

Info

Les colonnes CARÉGORIE, CRITICITÉ et STATUT sont remplies selon les équivalences configurées pour la synchronisation.

Un ticket synchronisé peut exister dans l'espace Exigences de Squash (en tant qu'exigence synchronisée), mais ce n'est pas obligatoire.

Si une issue est déplacée dans GitLab, par exemple dans un nouveau milestone, elle apparaît toujours à son emplacement d'origine dans Squash, mais n'est plus synchronisée. Elle reste dans l'état correspondant au dernier processus de mise à jour. Si son nouvel emplacement fait partie du périmètre de la synchronisation, elle sera synchronisée au nouvel emplacement.

Affichage

Dans la vue des tickets du sprint se trouve également une icône . Elle indique qu'il s'agit d'un ticket de sprint synchronisé, 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 : le ticket du sprint est toujours mise à jour par synchronisation ;
• icône jaune : le ticket du sprint n'est plus mise à jour par synchronisation car l'issue GitLab correspondante est déplacée dans une autre milestone ou itération, ou n'entre plus dans le périmètre de synchronisation. Si cette issue se retrouve dans l'élément GitLab initial (itération ou milestone), elle sera à nouveau mise à jour à l'emplacement initial dans Squash ;
• icône rouge : le ticket du sprint n'est plus mise à jour par synchronisation car l'issue GitLab correspondante a été supprimée ;
• icône noire : le statut de synchronisation du ticket est inconnu (par exemple, lorsque la synchronisation globale est en échec, ou que le milestone a été supprimé dans GitLab. Son contenu ne peut donc plus être synchronisé).

Suppression

Si un ticket de sprint synchronisé est supprimé d'un sprint non fermé, il sera recréé lors du prochain processus de mise à jour.

Attention

Si un ticket de sprint synchronisé supprimé est lié à des exécutions, elles seront supprimées définitivement, seul le ticket sera recréé par synchronisation.

Le groupe de sprints cible

Le groupe de sprints cible correspond au groupe de sprints dans lequel sont synchronisés les éléments GitLab (itérations ou milestones). Dans ces sprints sont synchronisés les issues, sous forme de tickets de sprint.

Modification, déplacement et suppression

Si le groupe de sprints cible est modifié (nom ou description), il sera toujours mis à jour lors des prochaines synchronisations, en conservant ses nouvelles informations.

Le groupe de sprints cible peut être déplacé dans l'arborescence des exécutions :

• le groupe de sprints est déplacé au sein du même projet : les sprints qu'il contient sont toujours mis à jour ;
• le groupe de sprints est déplacé dans un autre projet : les sprints qu'il contient deviennent des sprints manuels dans le projet de destination.

Si le groupe de sprints cible est déplacé dans un autre projet ou supprimé de Squash TM, il sera recréé à la prochaine synchronisation (dans le projet d'origine) s'il n'a pas été supprimé ou fermé côté GitLab.