Gérer les bugtrackers et serveurs de synchronisation
Bugtrackers vs serveurs de synchronisation
Dans Squash, il faut distinguer les plugins de bugtracking des plugins dédiés aux synchronisations.
Les plugins de bugtracking servent à la déclaration d'anomalies depuis Squash vers des outils tiers de type Bugtracker.
Les plugins de synchronisation servent à synchroniser dans Squash des tickets présents dans des outils tiers dédiés au suivi de projets IT.
Voici la liste des outils tiers avec lesquels peut s'interfacer Squash :
Nom du plugin | Catégorie | Type dans l'espace Serveurs | Outils tiers |
---|---|---|---|
Mantis REST Bugtracker | Bugtracking | mantis | Mantis |
Bugzilla Bugtracker | Bugtracking | bugzilla | Bugzilla |
GitLab Bugtracker | Bugtracking | gitlab.bugtracker | GitLab |
Jira Bugtracker Server et Data Center | Bugtracking | jira.rest | Jira Server, Jira Data Center |
Jira Bugtracker Cloud | Bugtracking | jira.cloud | Jira Cloud |
Xsquash4Jira | Synchronisation | jira.xsquash | Jira Server, Jira Data Center, Jira Cloud |
Workflow Automatisation Jira | Synchronisation | jira.rest ou jira.cloud | Jira Server, Jira Data Center, Jira Cloud |
Redmine Bugtracker | Bugtracking | redmine3.rest | Redmine |
Redmine Exigences | Synchronisation | redmine3.rest | Redmine |
Azure DevOps Bugtracker | Bugtracking | azuredevops.bugtracker | Azure DevOps |
RTC Bugtracker | Bugtracking | rtc | Rational Team Concert |
Tuleap Bugtracker | Bugtracking | tuleap | Tuleap |
En savoir plus
Il nécessaire d'installer le ou les plugin(s) correspondant(s) à l'outil pour accéder aux fonctionnalités de bugtracking ou de synchronisation. Certains plugins sont embarqués dans la distribution de Squash.
Pour en savoir plus sur les plugins, consulter les pages suivantes : Les plugins de Squash, Installer les plugins Squash.
Ajouter, modifier, supprimer un bugtracker et un serveur de synchronisation
La gestion des bugtrackers et serveurs de synchronisation est accessible depuis l'espace Administration, sous-menu Serveurs, via l'ancre Bugtrackers et serveurs de synchronisation .
Depuis le tableau de gestion des bugtrackers et serveurs de synchronisation, il est possible d'ajouter ou de supprimer des serveurs de façon unitaire ou en masse. Il est également possible de supprimer un bugtracker ou un serveur de synchronisation depuis sa page de consultation en cliquant sur le bouton [...].
Lors de la création d'un bugtracker ou d'un serveur de synchronisation, il faut renseigner un nom (libre), choisir le type de serveur dans la liste déroulante et renseigner l'URL de l'outil tiers. L'URL doit être la plus courte possible car elle sert de base à toutes les requêtes API utilisées par Squash pour communiquer avec l'outil tiers. Tous ces champs sont obligatoires.
En cliquant sur le numéro de ligne (#) ou le nom, la page de consultation du serveur s'affiche pour permettre sa modification. La barre des ancres permet de naviguer entre les différents blocs.
Attention
Lorsqu'un serveur de bugtracking est supprimé, il est automatiquement supprimé du projet auquel il était associé. La valeur "Pas de bugtracker" s'affiche sur la page de consultation du projet.
Toutes les associations avec les anomalies présentes dans les blocs Anomalies connues sont également supprimées.
Paramétrer un bugtracker ou un serveur de synchronisation
Pour qu'un bugtracker accepte d'échanger des informations avec Squash, ce dernier doit s'authentifier. La gestion de l'authentification permet de définir de quelle façon les utilisateurs ou Squash lui-même vont s'authentifier sur le serveur. Elle se décompose en deux blocs :
- le bloc Protocole d’authentification qui définit le protocole de sécurité utilisé pour authentifier la connexion ;
- le bloc Politique d’authentification qui détermine de quelle façon les utilisateurs et/ou Squash sont authentifiés.
Protocole d'authentification
Le bloc Protocole d'authentification permet de définir le protocole d'authentification. Les protocoles supportés par Squash sont "Basic Authentication", "OAuth 1A" (uniquement pour les connecteurs Jira), "OAuth 2.0" (uniquement pour les connecteurs Jira) et "Token Authentication" (uniquement pour les connecteurs GitLab, Mantis et Redmine). Les protocoles proposés à la configuration dépendent du type de bugtracker.
Focus
Lorsque l'on change le protocole d'authentification, l’effet est appliqué immédiatement. La configuration précédente est rendue obsolète et supprimée du serveur. Cependant les informations restent présentes dans la page tant que la page n'est pas fermée ou rafraîchie : si le protocole est modifié par erreur, il est possible de rétablir le protocole précédent et de sauvegarder à nouveau la configuration.
Basic Authentication
Basic Authentication est le protocole par défaut. L'authentification s'appuie sur la saisie du login et du mot de passe de l'utilisateur. Il est supporté par tous les serveurs sauf GitLab et Mantis. Il ne requiert pas de configuration supplémentaire. L'usage de Basic Authentication n’est considéré comme sécurisé qu’en conjonction avec SSL/TLS (https).
Jira Cloud
Jira Cloud nécessite un API Token à la place du mot de passe habituel pour se connecter bien que le protocole Basic Authentication soit utilisé.
Quelle que soit la politique d'authentification choisie, dans le champ Login, il faut renseigner l'adresse mail de l'utilisateur, et, dans le champ Jeton, renseigner le jeton généré pour le compte sur Jira Cloud.
La procédure à suivre pour générer un jeton est détaillée sur cette page : Créer un jeton d'API.
Azure DevOps
Azure DevOps nécessite un API Token à la place du mot de passe habituel pour se connecter bien que le protocole Basic Authentication soit utilisé.
Quelle que soit la politique d'authentification choisie, dans le champ Nom de l'organisation, il faut renseigner le nom de l'organisation Azure DevOps, et dans le champ Jeton, renseigner l'API token généré pour le compte de l'utilisateur sur Azure DevOps. Des droits Read & Write sur les Work Items sont suffisants.
La procédure à suivre pour générer un token est détaillée sur cette page : S'authentifier avec des jetons d'accès personnels dans Azure DevOps.
OAuth 1A
Ce protocole n’est pour l’instant exploité que par les connecteurs Jira. Il nécessite de configurer les URLs impliquées dans l’échange de jetons et les modalités de signature des requêtes. Les champs à renseigner dans le bloc Politique d'authentification sont un jeton et le secret du jeton.
En savoir plus
Pour en savoir plus, consulter la page Configurer le protocole d'authentification OAuth 1A.
OAuth 2.0
Ce protocole n’est pour l’instant exploité que par les connecteurs Jira. La configuration se fait à la fois dans Jira et dans Squash. Elle diffère selon le mode d'hébergement de Jira (Jira Server/Data Center ou Jira Cloud).
En savoir plus
Pour en savoir plus, consulter la page Configurer le protocole d'authentification OAuth 2.0.
Token authentication
Ce protocole n'est pour l'instant exploité que par GitLab, Mantis REST et Redmine. L'authentification s'appuie sur la saisie d'un jeton généré dans l'outil tiers et ne requiert pas de configuration supplémentaire.
GitLab
Pour générer un jeton sur GitLab, consulter la page Personal access tokens.
Mantis
Pour générer un jeton d'API Mantis, rendez-vous dans Mon compte (1), puis dans l'onglet Jetons de l'API(2).
Donner un nom explicite au Jeton afin de le révoquer si besoin (3), puis cliquer sur le bouton [Créer un jeton de l'API] (4) pour le créer.
Copier le jeton généré et le coller dans le champ Squash prévu à cet effet selon la politique d'authentification choisie.
Redmine
Pour générer un jeton d'API sur Redmine, rendez-vous dans Mon Compte (1) puis afficher la Clé d'accès API (2).
Copier le jeton généré et le coller dans le champ Squash prévu à cet effet selon la politique d'authentification choisie.
Politique d'authentification
Le bloc Politique d'authentification permet de configurer le choix d'authentification des utilisateurs pour le bugtracker ou le serveur de synchronisation.
-
Les utilisateurs s'identifient eux-mêmes : chaque utilisateur doit s'identifier personnellement à l'outil tiers. La procédure varie suivant le protocole choisi. Dans le cas d'une Basic Authentication, il doit saisir son login et mot de passe de connexion à l'outil tiers dans Squash, tandis que pour une Token Authentication, il doit saisir un jeton d'accès généré dans l'outil tiers. Pour OAuth 1A, l'authentification est déléguée au serveur tiers dans une fenêtre distincte ;
-
Utiliser les identifiants du compte technique du serveur : les utilisateurs n'ont plus à s'authentifier et le serveur utilise automatiquement les identifiants d'accès à l'outil tiers renseignés dans le champ Identifiants du compte technique de nom_du_serveur. Quel que soit l'utilisateur connecté dans Squash, les données sont remontées vers l'outil tiers avec les identifiants de l'utilisateur renseigné dans le bloc.
Info
L'option Les utilisateurs s'identifient eux-mêmes est conseillée pour la configuration des bugtrackers. Le nom de l'utilisateur est ainsi renseigné comme rapporteur de l'anomalie, à la place d'un utilisateur commun. Cela permet d'avoir une traçabilité des échanges entre l'outil tiers et Squash.
L'option Utiliser les identifiants du compte technique du serveur peut être utilisée lors de la configuration d'un serveur de synchronisation, notamment pour Xsquash4Jira et Xsquash4GitLab si l'on souhaite effectuer les synchronisations avec un compte technique, ainsi que le plugin Workflow Automatisation Jira.
Le champ Identifiants du compte technique de nom_du_serveur est à renseigner uniquement si l'option Utiliser les identifiants du compte technique du serveur est cochée.
Pour que les champs soient enregistrés en succès, il faut que :
- l'outil tiers soit joignable ;
- les identifiants de connexion à l'outil tiers soient corrects ;
- le compte associé à ces identifiants dispose des permissions nécessaires sur l'outil tiers ;
- la configuration du serveur soit correcte.
Info
Squash persiste en base de données certaines informations concernant l'authentification. Ceci inclut la configuration de protocole, les identifiants applications de Squash et les jetons OAuth des utilisateurs le cas échéant. Les logins et mots de passe personnels des utilisateurs (Basic Authentication) sont sauvegardés chiffrés dans la base de données.