Newsletter Avril 2020

Browser une Collection

Une fois que vous avez recueilli les Documents et leurs Baselines, vous pouvez ouvrir la Collection et travailler dans une interface ciblée, qui ne montre que les Documents, les liens et les actions pertinentes à la Collection. Un utilisateur peut utiliser cette vue simplifiée pour travailler dans le contexte de la Collection en toute indépendance des objets qui n’appartiennent pas à la Collection mais qui sont toujours présent dans Polarion.

Lier des Work Items dans le contexte de la Collection

La collection vous permet également de relier des Work Items entre eux avec une validation des liens en temps réel, ce qui assure leur cohérence au sein même de la Collection. En d’autres termes vous ne pouvez lier les Work Items d’une même Collection que lors de l’ouverture du lien dans le contexte de la Collection.

Fonctionnalités supplémentaires des Collections

Vous pouvez :

• Fermez une Collection et la verrouiller pour une modification ultérieure.

• Configurer les custom fields de de la Collection et les permissions d’utilisateur.

• Configurer la préférence « par projet », que ce soit pour masquer ou afficher les liens des Work Items menant à une Collection par défaut.

D’autres fonctionnalités seront implémentées dans de prochaines versions comme les Collections cross-projets.

Connecteur Jenkins

Intégration Polarion avec Jenkins CI/CD

La complexité des produits d’aujourd’hui et de demain est difficilement gérable sans automatisation, particulièrement quand il s’agit de la grande diversité des variantes de produits et l’impact sur le logiciel qui se doit de supporter toutes ces variantes. Dans le domaine du logiciel, l’un des outils les plus populaires pour l’Intégration Continue / Livraison Continue (CI/CD en anglais) est l’outil open-source Jenkins.

Polarion supporte la technologie d’Intégration Continue (CI/CD) au moyen d’un Connecteur que les administrateurs peuvent configurer pour se connecter et échanger des données avec un système CI/CD distant. Cela permet à Polarion de lancer des builds et des tests qui sont effectués par une application externe (Jenkins) et d’importer ensuite les résultats de ces builds et tests.

 

Configurer le connecteur Jenkins

Ce connecteur permet à Polarion d’être « pluggé » dans une chaîne DevOps en se connectant à n’importe quel serveur Jenkins via HTTP/S avec authentification via un mot de passe utilisateur ou un jeton API. Le connecteur peut être configuré via l’onglet d’administration Building > CI/CD Integration.

Lorsque la connexion est établie, les Builds peuvent être configurés. Vous aurez besoin notamment de connaître l’URL du Jenkins Build distant. La configuration des paramètres peut être soit une partie statique de la configuration Build, soit, si le Build est déclenché par le workflow de Polarion, les valeurs peuvent être chargées dynamiquement à partir d’un champ personnalisé d'un Work Item ou d'un Test Run.

Un Build dans Jenkins représente un build, un test, ou une combinaison des deux, exécutés en série.

Déclenchement de builds Jenkins depuis Polarion

Les builds configurés peuvent être déclenchés de plusieurs façons. Le plus simple est de commencer un build manuellement en utilisant l’onglet Polarion Builds. Les Builds peuvent également être programmés via le Polarion Scheduler et s’exécutent automatiquement. La troisième option pour déclencher les Builds est via les fonctions de workflow des Work Items ou Test Runs qui vous permettent d’exécuter les Builds dans le cadre d’un changement de statut. Cette troisième option apporte une valeur ajoutée aux environnements hautement intégrés où le développement est étroitement lié et suivi dans Polarion.

Supervision des builds Jenkins dans Polarion

Lorsqu’un build Jenkins est exécuté depuis Polarion, il est ensuite monitoré via un polling Jenkins pour récupérer les données actualisées. Le numéro de Build et le statut du Build sont alors récupérés de Jenkins et stockés sur la page Build de l’onglet Builds de Polarion. Ces informations peuvent également être stockées dans des champs personnalisés de Work Items ou de Test Runs si le processus a été déclenché par une fonction Workflow, en incluant un lien vers le Build Polarion qui a été créé lorsque le build distant a été déclenché.

Accès aux artéfacts de Build et résultats des tests

Par défaut, l’ensemble de tous les artefacts de build sont chargés dans Polarion quand un Build se termine. Cet ensemble d’artefacts peut être filtré pour éviter de charger des données inutiles.

Jenkins est fréquemment utilisé pour exécuter des tests automatisés. Si ces tests écrivent les résultats des tests dans un fichier xUnit, Polarion permet aux utilisateurs d’importer les résultats des tests vers des Test Runs existants, ou de créer de nouveaux Test Runs par le processus d’importation.

Synchronisation des groupes d’utilisateurs via LDAP

La version 20 R1 vous permet désormais d’affecter automatiquement les utilisateurs à des groupes d’utilisateurs en les synchronisant avec des groupes LDAP.

Chaque groupe d’utilisateurs peut être relié à LDAP via un filtre de recherche LDAP. Si ce champ optionnel dans les détails d’un groupe d’utilisateurs est vide, le groupe d’utilisateurs ne sera pas synchronisé avec LDAP. Si ce champ n’est pas vide, la synchronisation LDAP tentera de mettre à jour les utilisateurs du Groupe sur la base de la query LDAP saisie dans ce champ.

Déclencher la synchronisation LDAP via un job

 La synchronisation LDAP peut être déclenchée manuellement ou automatiquement via un job, qui offre la possibilité d’ajuster la synchronisation en fonction des paramètres pris en charge.

Affichage de l’origine des rôles dans l’administration des utilisateurs et des rôles

Parce que les rôles peuvent être attribués aux utilisateurs directement ou via un groupe d’utilisateurs, il est important de savoir comment l’affectation a été faite. Une nouvelle colonne Source a été ajoutée aux sections Global Roles et Project Roles de la page d’administration des utilisateurs, et à la section Utilisateurs de la page d’administration des rôles. Cette colonne indique à l’administrateur si un rôle a été directement attribué ou provient d’un ou plusieurs groupes d’utilisateurs (et répertorie alors tous les groupes d’utilisateurs).

Performance et scalabilité

Nos équipes de développement travaillent progressivement à l’amélioration des performances et de scalabilité de Polarion. La version 20 R1 apporte un certain nombre d’améliorations sur presque l’ensemble des fonctionnalités Polarion.

Nouvelle Recherche de l’historique

Polarion ne gère pas de la même façon les données de la version Head et celles des versions précédentes, et différents mécanismes et algorithmes sont utilisés pour rechercher et traiter ces données. Le moteur de recherche Polarion a été entièrement retravaillé. Certains cas d’utilisation sont aujourd’hui nettement améliorés (les trend charts, par exemple) tandis que d’autres ont des performances similaires à celles d’avant. La scalabilité de l’algorithme a été améliorée de sorte que l’ensemble des opérations sur l’historique est maintenant bien plus performant, avec une allocation de mémoire plus petite, en particulier lorsque qu’il y a une montée en charge due à des centaines d’utilisateurs connectés simultanément au serveur Polarion.

Les avantages mesurables de cette refonte comprennent :

• Exécution plus rapide de 90% pour les recherches Lucene dans l’historique,

• Exécution plus rapide de 95% pour les recherches SQL dans l’historique,

• Ouverture plus rapide de 95% des Documents et des Pages historisés,

• Lazy Loading plus rapide des Work Items dans les LiveDocs quand la liste des Linked Work Items est affichée dans le document

• Affichage plus rapide de vues comparatives de Documents,

• Rendu initial plus rapide des widgets trend chart,

• Durée raccourcie du job du DB History Creator après le redémarrage de Polarion en quelques minutes

Polarion crée ce qu’on appelle des «baseline views» pour filtrer le résultat brut de la recherche d’historique Lucene afin d’obtenir uniquement les objets qui existent réellement dans la baseline spécifiée. Par défaut, Polarion précharge en cache les baseline views des 180 derniers jours, ce qui assure un rendu initial rapide des graphiques de tendance qui remontent jusqu’à 6 mois en arrière. Un tuning additionnel permet d’améliorer les performances des recherches dans l’historique plus ancien, mais au détriment d’une consommation accrue de mémoire.

Chargement de Documents et Pages dans le panneau de navigation

Polarion 20 R1 améliore le chargement des documents et pages, en particulier dans le cas de milliers de documents et rapports qui sont directement présent dans un projet Polarion. En fonction du paramétrage, l'affichage d’objets dans le panneau de navigation s’affranchi des vérifications sur les permissions, ce qui se traduit par une accélération de l’ordre de 80 %. Ainsi les utilisateurs peuvent voir le titre des d’objets restreints dans le panneau de navigation, sans qu'ils puissent ouvrir le document ou la page.

Form Extensions

Suite à l’option fournie dans Polarion 19.3 permettant de charger les Work Items Form Extensions de façon asynchrone, celle-ci devient en version 20 R1 la seule option, ce qui garantit aux utilisateurs d’obtenir les données Polarion rapidement, le contenu externe des sections scriptées du Work Item étant traité en arrière-plan.

Rafraîchissement de l’interface Utilisateur

Polarion 20 R1 délivre les résultats de la première phase du rafraîchissement de l’interface utilisateur.  Cette première phase a consisté en une mise à jour des couleurs, icônes et de la typographie. Cette phase fut une condition préalable pour la phase deux pour une transition progressive vers l’UI envisagée pour Polarion à venir. Nous avons également apporté des améliorations à un certain nombre de pages de l’Administration. Pour plus de détails sur ce que vous trouverez en 20 R1, et ce que nous avons prévu pour l’avenir, consultez le blog Polarion : Sneak Preview - Visual Refresh Polarion 20.

Autres améliorations

Connecteur Jira : support de la synchronisation des champs Jira « multi-select »

Nous travaillons continuellement sur l’amélioration de nos connecteurs existants. Polarion 20 R1 prend désormais en charge la synchronisation des champs Jira de type "multi-select" avec des champs Polarion de type "Custom Multi Enum", ce qui permet de synchroniser des listes de valeurs entre les deux outils.

Merge configurable et cible source pour GitLab

Vous pouvez maintenant configurer les branches source et cible pour l’extension merge request de GitLab.

<extension id="GitLabExtension" label="Merge Request Panel"

sourceBranchNameField="[name of custom field with working branch name]"

targetBranchNameField="[name of custom field with target branch name]"/>

Vous pouvez également coder en dur la branche cible en utilisant uniquement le paramètre targetBranchName.

Support du nouveau MS Edge

Il convient également de mentionner le fait que Polarion prend en charge le nouveau navigateur Microsoft Edge basé sur Chromium qui gagne rapidement en popularité. Les anciennes versions MS Edge ne sont plus supportées.

Les informations sur les navigateurs actuellement pris en charge et les versions de navigateur sont maintenant fournies dans les chapitres des exigences du système des guides d’installation pour Linux et Windows, et dans l’aide en ligne.

Modifications apportées au référentiel Maven bundled

Le référentiel Maven livré avec Polarion a été modifié et ne comprend plus de librairie tierce. En conséquence les calculs et builds peuvent démarrer en se connectant au référentiel central Maven accessible sur Internet. Si votre serveur Polarion n’a pas de connexion au référentiel central Maven, vous devrez utiliser un Maven repository manager.

Couverture élargie de l’API WebService

Trois nouveaux appels WebService ont été ajoutés au TrackerWebService :

• Get Attachment

• Export Document to PDF

• Delete Work Item

 

Enfin pour connaitre tous les détails des évolutions et corrections apportée par cette nouvelle version Polarion 20 R1 nous vous invitions à vous rendre sur le Polarion Blog.

Voici comment se présente un tableau de traçabilité généré par ce widget sur une page Polarion

S’il est très utilisé, certains paramètres intéressants ne sont cependant pas bien connus, et nous allons donc nous concentrer sur ces critères (le menu About This Widget donne également accès à l'aide associé). Auparavant, un point rapide sur les données en entrée standards de ce widget, il s'agit de :

• Renseigner le type et le titre du Work Item présenté en première colonne

• Choisir les attributs présentés (display work item fields), affichés par défaut ou non (collapse fields by default)

• Ajouter d'autres colonnes avec d'autres types de Work Items

• Choisir le type de lien (Link Rôle)

Paramètres à connaître :

Sous Polarion, nous pouvons lier des Works Items (ex: exigences logicielles ) au code source qui les implémentent ( fonctionnalité Resource Traceability de Polarion ). C'est l'objectif de l'option Display Link to Resources qui liste ainsi dans la cellule les programmes liés, comme ci-dessous dans la colonne Software Requirements :

Enfin, quand nous présentons les cas de test, il peut être intéressant d'afficher par l'option Display Last Test Exécution Results le résultat de la dernière exécution de ce cas de test, à savoir donc le résultat du dernier TestRun. Une option complémentaire Display Test Step Results affiche le détail des étapes de test, dans le cadre d'une exécution manuelle de ce test.

Il existe d'autres options que nous ne détaillons pas ici, comme par exemple la possibilité de choisir en colonne un type de document, plutôt qu'un type de Work Item. Il peut enfin être intéressant de combiner ce widget avec des paramètres de page, par exemple variabiliser le choix de l'affichage des suspects ou de la visibilité des attributs. Pour cela, il faut récupérer le code source du widget, consultez-nous si vous avez des interrogations sur le mode opératoire !

Utiliser des Work Items comme une énumération !

Cette extension est sans doute moins connue, mais pourtant fort utile car elle ouvre des portes sur la façon de structurer les données dans un référentiel Polarion: https://extensions.polarion.com/extensions/350-custom-enumeration-factories

Imaginez que vous ayez une exigence et que vous voulez catégoriser cette exigence par un attribut relative à ce système.

Option 1 : Vous créez une énumération avec les valeurs des systèmes à l'instant t, mais quid de l'ajout d'un nouveau système ? Ceci vous oblige à rajouter une valeur dans l'énumération, et donc demander à un administrateur du projet de procéder à ce changement.

Nous pourrions faire la même chose pour un champ Release ! Plutôt qu'avoir un champ targetRelease qui va trouver ses valeurs dans une énumération peu dynamique de targetRelease, ce champ devient une énumération de Work Items Release !