Gérer les synchronisations Xsquash4GitLab dans Squash TM
Info
Cette page est dédiée à la gestion des synchronisations Xsquash4GitLab. Pour la configuration générale du plugin, consulter la page Configurer Xsquash4GitLab dans Squash TM.
Pour en savoir plus sur les fonctionnalités de Xsquash4GitLab, consulter la page Synchroniser des objets agiles GitLab dans Squash.
Une synchronisation est l'unité de travail du plugin Xsquash4GitLab. Elle représente l'ensemble des issues GitLab définies par un périmètre dynamique qui sont récupérées dans Squash TM. Ce périmètre dynamique est recalculé à chaque processus de mise à jour. Par défaut, le délai est de cinq minutes entre chaque processus de synchronisations (ce délai est configurable dans le fichier de configuration Squash TM).
Le périmètre de synchronisation est défini par deux éléments :
- l'emplacement des issues : il correspond au groupe ou projet dans lequel se trouvent les issues à synchroniser ;
- le type de synchronisation : pour l'emplacement sélectionné, il permet de définir si les issues à synchroniser doivent correspondre à des filtres appliqués sur leurs champs ou se trouver dans un board GitLab.
Voici le périmètre récupéré en fonction du type de synchronisation choisi :
| Emplacement des issues | Type de synchronisation | Périmètre de synchronisation | Note |
|---|---|---|---|
| Groupe ou Projet | Filtres sur les issues | L'ensemble des issues du groupe ou projet qui correspondent aux filtres appliqués sur leurs champs. Dans le cas où l'emplacement sélectionné est un groupe, les issues renvoyées sont celles contenues dans les projets du groupe sélectionné. | Le contrôle du périmètre est effectué côté Squash TM. |
| Groupe ou Projet | Board | L'ensemble des issues contenues dans un tableau du groupe ou projet sélectionné, en tenant compte de sa configuration. | Le contrôle du périmètre est délégué à GitLab. Si la configuration du tableau est modifié côté GitLab, le périmètre dans Squash TM est modifié, sans préavis ni message. Si le tableau est supprimé dans GitLab, la synchronisation échoue avec un message dans les logs. |
Le bloc Synchronisations se présente ainsi :
Les chapitres suivants détaillent l'utilisation de cette table.
Créer une synchronisation
Pour créer une synchronisation, cliquer sur le bouton 
présent au sommet du bloc Synchronisations.
Synchronisation d'exigences (Espace Exigences)
Cette première étape de la création d'une synchronisation est obligatoire.
Le tableau suivant détaille le fonctionnement des champs de la pop-up et comment les renseigner :
| Nom | Obligatoire | Modifiable | Commentaire |
|---|---|---|---|
| Nom | Oui | Oui | Nom libre. Il doit être unique sur l'ensemble de l'instance Squash TM. |
| Chemin Cible | Oui | Non | Chemin initial du répertoire cible de la synchronisation. Ce chemin est créé par Xsquash4GitLab au premier cycle de synchronisation. |
| Serveur | Oui | Non | Serveur Xsquash4GitLab utilisé pour cette synchronisation, à choisir dans la liste des serveurs paramétrés dans l'écran d'administration des Bugtrackers et serveurs de synchronisation. |
| Périmètre | Oui | Non | Chemin du groupe, sous-groupe ou projet où se trouvent les issues à synchroniser. Il doit être indiqué tel qu'il apparaît dans l'URL de GitLab (ex : groupe-1/sous-groupe-1/projet-1 pour synchroniser les issues du "Projet 1", ou groupe-1 pour synchroniser les issues des projets contenus dans le "Groupe 1"). |
| Sélection par | Oui | Non | Type de synchronisation. Deux options possibles : Issue ou Board. En fonction de l'option choisie, les champs suivants de la pop-up changent. |
| Organisation par | Oui | Non | Manière dont sont organisées les issues synchronisées dans la bibliothèque des exigences de Squash TM. Quatre options possibles selon le type de synchronisation : - À plat (Issue) : toutes les issues GitLab sont synchronisées à la racine du répertoire de synchronisation - Iteration (Issue et Board) : un répertoire est créé pour chaque iteration contenue dans le périmètre - Milestone (Issue et Board) (sélectionnée par défaut) : un répertoire est créé pour chaque milestone contenu dans le périmètre - Arborescence (Issue) : dans le cas où le périmètre est un groupe, un répertoire est créé pour chaque sous-groupe et projet. |
| Board | Oui | Oui | Tableau à synchroniser. S'affiche uniquement si le champ 'Périmètre' est renseigné et pour les synchronisations par Board. |
| Filtres actifs | Non | Oui | Permet d'affiner le périmètre en appliquant des filtres sur les champs des issues. Permet notamment de limiter la synchronisation à l'itération ou milestone en cours. Disponible uniquement pour les synchronisations par Issue. |
| Synchronisation des sprints dans l'espace Exécutions | - | Oui | Si coché, permet d'accéder à une étape supplémentaire afin de de configurer la synchronisation dans l'espace Exécutions (Sprints). Disponible uniquement pour les synchronisations dont l'organisation est par Milestone ou par Itération. |
Restrictions du chemin cible
Le chemin cible ne peut pas :
- Pointer exactement vers un dossier synchronisé, ou être identique à celui d'une synchronisation déjà configurée ;
- Débuter ou finir par un espace ou un
/; - Inclure une série de plusieurs espaces à la suite ;
- Avoir un espace situé directement avant ou après un
/.
Simuler une synchronisation d'Exigences
Lors de l'ajout d'une nouvelle synchronisation, une simulation de la synchronisation est exigée avant de confirmer sa création ou de passer à l'étape suivante.
Pour cela, un bouton [Simuler] figure dans la première étape de la fenêtre d'ajout de synchronisation. Il permet de visualiser le nombre et le détail d'issues que contient la synchronisation pour vérifier que cela correspond au périmètre voulu.
Info
Si une valeur est déterminée pour limiter le nombre d'éléments à synchroniser (voir la gestion du fichier de configuration Squash TM), cette valeur est aussi prise en compte lors de la simulation, et celle-ci échoue si le nombre d'issues à synchroniser est trop élevé.
Synchronisation de sprints (Espace Exécutions)
Cette seconde étape est facultative, et n'est accessible qu'avec une Organisation par Milestone ou par Itération et si la case Synchronisation des sprints dans l'espace Exécutions est cochée.
Le tableau suivant détaille le fonctionnement des champs de la pop-up et comment les renseigner :
| Nom | Obligatoire | Modifiable | Commentaire |
|---|---|---|---|
| Chemin cible pour la synchronisation des sprints | Oui | Oui | Chemin initial cible où sont synchronisés les sprints. Ce chemin est créé par Xsquash4GitLab au premier cycle de synchronisation. L'élément final du chemin est un groupe de sprints, tandis que les éventuels éléments précédents du chemin sont des dossiers. |
| Périmètre | Oui | Non | Chemin du groupe, sous-groupe ou projet où se trouvent les issues à synchroniser. La valeur est identique à la première étape. |
| Gestion des sprints | Oui | Non | Objet GitLab utilisé pour la gestion des sprints (milestone ou itération). La valeur est identique au champ "Organisation par" de la première étape. |
| Sélection par | Oui | Oui | Type de synchronisation. Deux options possibles : Issue ou Board. En fonction de l'option choisie, les champs suivants de la pop-up changent. |
| Filtres actifs | Non | Oui | Permet d'affiner le périmètre en appliquant des filtres sur les champs des issues. Permet notamment de limiter la synchronisation à l'itération ou milestone en cours. Disponible uniquement pour les synchronisations par Issue. Si des filtres sont sélectionnés à la première étape, il sont sélectionnés par défaut ici. |
| Board | Oui | Oui | Tableau à synchroniser. S'affiche uniquement si le champ 'Périmètre' est renseigné et pour les synchronisations par Board. Si un tableau est sélectionné à la première étape, il est sélectionné par défaut ici. |
| Équivalences | Non | Oui | Il est possible d'indiquer un ou plusieurs labels GitLab correspondant à la Catégorie, à la Criticité et au Statut de l'issue. Les labels doivent exister et se trouver dans le projet et/ou le groupe GitLab correspondant au périmètre. Les valeurs des labels configurés seront synchronisées et affichées pour chaque ticket de sprint dans Squash. |
Restrictions du chemin cible
Le chemin cible ne peut pas :
- Pointer vers un groupe de sprint déjà existant dans l'espace Exécutions, ou débuter par un chemin déjà configuré dans une autre synchronisation ;
- Débuter ou finir par un espace ou un
/; - Inclure une série de plusieurs espaces à la suite ;
- Avoir un espace situé directement avant ou après un
/.
Simuler une synchronisation (pour l'espace Exécutions)
Lors de l'ajout d'une nouvelle synchronisation, une simulation de la synchronisation est exigée avant de confirmer sa création.
Pour cela, un bouton [Simuler] figure dans la seconde étape de la fenêtre d'ajout de synchronisation. Il permet de visualiser le nombre et le détail des issues, des milestones et/ou des itérations que contient la synchronisation pour vérifier que cela correspond au périmètre voulu.
Attention
Les sprints créés dans l'espace Exécutions dépendent du statut du milesone ou de l'itération dans GitLab :
- À venir / Ouvert / Expiré : le sprint et ses tickets sont créés ;
- Fermé / Supprimé : le sprint et ses tickets sont ignorés.
Info
Si une valeur est déterminée pour limiter le nombre d'éléments à synchroniser (voir la gestion du fichier de configuration Squash TM), cette valeur est aussi prise en compte lors de la simulation, et celle-ci échoue si le nombre d'issues à synchroniser est trop élevé.
Suivi des synchronisations
Une fois la synchronisation configurée, une ligne supplémentaire apparaît dans la table des synchronisations. À la prochaine mise à jour, l'ensemble des exigences et sprints synchronisés qui correspondent au périmètre sont créés. Si la synchronisation échoue, rien n'est créé dans Squash TM. Le statut de chaque synchronisation est affiché dans la table des synchronisations.
Le bouton 
permet de rafraîchir le tableau des synchronisations pour voir si leur statut a évolué suite au passage du processus de mise à jour.
Modifier une synchronisation existante
Il est possible de modifier certains éléments de la configuration de synchronisation une fois celle-ci créée. Après modification, lors du prochain processus de mise à jour, seule la dernière version de la configuration sera prise en compte.
Ainsi, si certaines issues GitLab ne font plus partie du périmètre défini, elles ne seront pas mises à jour dans Squash TM.
Modifier la synchronisation d'exigences
La colonne SYNC. EXI. affiche quel type de synchronisation est sélectionné (Board ou Issue). Le bouton 
permet de voir et de modifier la configuration de la synchronisation d'exigences.
Seuls les filtres (pour une sélection par Issue) ou le tableau (pour une sélection par Board) sont modifiables.
Une simulation est obligatoire avant de pouvoir valider les modifications.
Ajouter une synchronisation de sprints (espace Exécutions)
Si une synchronisation d'exigences existante permet de configurer une synchronisation de sprints, la colonne SYNC. SPRINT indique si celle-ci est déjà configurée (Oui ou Non). Si ces conditions ne sont pas respectées, un - est affiché.
Si "Non" est indiqué, le bouton permet d'ajouter une synchronisation de sprints.
Comme pour la création d'une synchronisation, le périmètre ainsi que le type de gestion des sprints sont repris de la configuration de synchronisation des exigences, et ne sont pas modifiables.
Les champs Chemin cible, Sélection par, Filtres, ou Board, ainsi que les Équivalences sont modifiables et leur fonctionnement est identique à celui décrit lors de la seconde étape de création d'une synchronisation.
Une simulation est obligatoire avant de pouvoir valider.
Modifier une synchronisation de sprints (espace Exécutions)
Si la colonne SYNC. SPRINT indique "Oui", le bouton permet de voir et de modifier la configuration de la synchronisation de sprints.
Le fonctionnement est identique à l'ajout d'une nouvelle synchronisation de sprints, à l'exception du Chemin cible qui n'est pas modifiable.
Une simulation est obligatoire avant de pouvoir valider les modifications.
Supprimer une synchronisation de sprints
Un bouton [Supprimer] est présent dans la fenêtre de modification d'une synchronisation de sprints. Cliquer sur ce bouton supprime la configuration de synchronisation pour l'espace Exécutions.
Comme pour la suppression complète d'une synchronisation, les sprints synchronisés sont alors transformés en sprints manuels, ne sont plus mis à jour depuis GitLab et se comportent comme n'importe quel autre sprint de Squash TM. Il en va de même pour les répertoires synchronisés (répertoires cibles, groupes de sprints). Si l'utilisateur désire supprimer ces entités, il doit le faire manuellement comme pour n'importe quelle entité de Squash TM.
Info
La synchronisation d'exigences n'est pas impactée, et les exigences synchronisées continuent de l'être.
Forcer une synchronisation complète
Par défaut, le plugin ne met à jour que les exigences synchronisées qui ont été modifiées dans GitLab depuis le dernier processus de mise à jour connu et en succès.
Dans le cas d'un changement d'équivalences de champ ou de valeur côté Squash TM, il est nécessaire de resynchroniser l'ensemble des exigences côté Squash TM, même si rien n'a changé côté GitLab.
Le bouton 
permet de forcer la mise à jour de l'ensemble des issues synchronisées qui sont dans le périmètre actuel d'une ou plusieurs synchronisations.
Info
Afin d'éviter des processus de mises à jour inutiles, il est conseillé de faire les équivalences avant de déclarer les synchronisations.
Si les équivalences doivent évoluer par la suite, il est conseillé de faire toutes les évolutions d'équivalences de champs et de valeurs, puis de forcer une seule fois toutes les synchronisations du projet.
Désactiver une synchronisation
Le bouton radio présent en début de ligne permet de désactiver ou de réactiver une synchronisation sans la supprimer.
Lorsqu'une synchronisation est désactivée, les issues, les milestones et les itérations présents dans son périmètre ne sont plus synchronisés. La ligne est grisée et le nom de la synchronisation n'est plus modifiable, mais il est toujours possible de supprimer la synchronisation ou modifier ses configurations (synchronisations d'exigences et/ou de sprints).
Lorsqu'elle est réactivée, les issues, les milestones et les itérations sont de nouveau synchronisés dans Squash TM et reprennent les attributs de synchronisation ainsi que les équivalences et le reporting définis dans les autres blocs.
Supprimer une synchronisation
Le bouton 
permet de supprimer une ou plusieurs synchronisations. En accord avec la politique de non-suppression, les exigences et les sprints synchronisés ne sont pas supprimés mais transformés en objets natifs de Squash TM.
Ils ne sont plus mis à jour depuis GitLab et se comportent comme n'importe quelle autre exigence ou sprint de Squash TM. Il en va de même pour tous les répertoires synchronisés (répertoires cibles, groupes de sprints, répertoires d'iterations, milestones, projets).
Si l'utilisateur désire supprimer ces entités, il doit le faire manuellement comme pour n'importe quelle entité de Squash TM.