A la suite de mon dernier article sur Automation (que vous pouvez consulter ici), j’ai pu saisir l’enthousiasme des utilisateurs JIRA pour installer et configurer Automation dans leur propre instance JIRA. Mais cela fait presque un an déjà et grâce à la Communauté Atlassian, de nouvelles versions sont sorties afin d’enrichir les nouvelles fonctionnalités.
Dans ce nouvel article, j’ai décidé de vous donner un avant-goût de ces nouveautés et de vous montrer comment les utiliser. Comme toujours, je suis impatiente de lire vos commentaires et de connaitre vos retours sur cet add-on. 🙂
Quelques rappels sur Automation
Automation fait partie des milliers d’extensions disponible sur la marketplace d’Atlassian. Elle est gratuite et disponible pour les instances installées sur un serveur.
La marketplace vous dira qu’elle n’est pas supportée mais les contributeurs sont très réactifs sur le Bitbucket de l’extension.
Cet outil vous permet d’automatiser des tâches généralement répétitives au sein de JIRA afin de permettre à vos managers, administrateurs ou même utilisateurs de gagner du temps.
En tant qu’extension, seuls les administrateurs JIRA peuvent définir de nouvelles automations.
Quelles sont les nouvelles configurations disponible ?
Avant de parler des règles que vous pouvez créer, voici un bref rappel des nouvelles configurations disponibles dans l’onglet “Configuration” d’Automation.
– Rule logging : cela permet d’enregistrer les changements affectés aux demandes directement sur l’écran de vue de l’issue au lieu de l’onglet “Audit Log” d’Automation. Cette information pourra ensuite être retrouvée à partir d’une requête JQL.
– Synchronous process : cela permet d’activer le mode ‘synchronisé’ lors du déclenchement des règles.
L’autre nouvelle fonctionnalité que tous les utilisateurs d’Automation attendaient est la capacité à importer des règles existantes. En effet, lorsque vous créez vos demandes sur votre instance de développement, il parait logique de l’exporter pour l’importer en production au lieu de les recréer manuellement.
Depuis la version 1.3 d’Automation, le processus de création des règles n’a pas changé :
- Création de la règle avec le nom, l’utilisateur
- Sélection du trigger (à partir d’un évènement ou d’une date/intervalle précis)
- Ajout de l’action (quel élément souhaitez-vous modifier ou déclencher)
- Confirmation de votre nouvelle règle
Cependant lors de la troisième étape, vous pourrez choisir de nouvelles actions que je vais détailler ci-dessous.
Nouvelles actions de règles disponible
Edit Issue Action
Cette action existait déjà lors de la précédente version d’Automation. Cependant, une nouvelle option est désormais disponible.
L’édition de champs est un élément essentiel lorsque vous souhaitez rendre prioritaire votre issue (auto-escalation).
En effet, un grand nombre d’entreprises souhaitent changer automatiquement la priorité, l’assignee ou encore des champs personnalisés en fonction d’une valeur de temps passé ou encore d’une autre valeur de champ présente dans la demande. Avec cette nouvelle option, vous allez pouvoir modifier la valeur d’un champ avec la valeur d’un autre champ, autrement dit, l’utilisation de variables. Ces variables peuvent être définies à partir de champs JIRA (sommaire, description, priorité …) ou de champs personnalisés que vous avez créés pour votre instance.
Un exemple d’utilisation est d’automatiser le nom de votre demande avec la clé de votre demande en tant que préfixe (c’est-à-dire summary = issuekey + summary).
Malheureusement seuls les champs numériques et textuels peuvent être utilisés pour cette version, mais j’ai bon espoir de voir les champs utilisateurs ou date ajoutés dans les prochaines versions 🙂
Je vous laisse essayer cette nouvelle fonctionnalité pour en comprendre tous les avantages.
Transition Issue Action
A partir de maintenant, lorsque vous déclenchez des transitions automatiquement, vous pourrez passer les conditions de votre workflow.
Edit User Profile Action
Cette nouvelle action vous permet d’ajouter de nouvelles propriétés au profil utilisateur.
Personnellement, je l’utilise afin de définir l’entreprise de l’utilisateur. En effet lorsqu’un utilisateur créé une requête, c’est un atout pour mon assignee de savoir pour quelle entreprise cette requête a été créée. Notez également qu’une case à cocher est disponible si toutefois vous souhaitez donner une nouvelle valeur à votre champ (si une valeur existe déjà).
Concernant mon cas d’utilisation, la configuration est la suivante :
- Chaque utilisateur est lié à une entreprise grâce à un groupe.
- Cependant mon utilisateur appartient à plusieurs groupes (jira-users, managers, jira-administrators…).
- Grâce à l’extension JIRA Toolkit (gratuite !!!), je vais pouvoir afficher une (ou plusieurs) propriétés de mon reporter.
- Dans ma règle Automation, le trigger sera l’évènement de création de l’issue.
- Mon filtre sera “reporter in members Of (“Valiantys”)”
Soyez prudent: si votre utilisateur appartient à plusieurs groupes d’entreprise, vous devez avoir un filtre très précis.
Publish Event Action
Publier des évènements va vous permettre de passer outre les évènements de post-functions dans vos workflows et de déclencher des notifications quand vous en avez besoin.
Voici le cas pratique auquel je peux penser :
- Je travaille avec des fournisseurs au sein de mon entreprise.
- J’ai défini un champ personnalisé “Fournisseur” pour connaitre quelle autre entreprise travaille sur ma demande.
- Cette valeur est définie en même temps que l’assignee.
- L’assignee de cette issue restera mon développeur interne qui sera en charge de cette demande et des relations avec le fournisseur.
- Je vais créer de nouveaux évènements pour chaque fournisseur.
- Dans l’administration de mon projet, je vais m’assurer que chaque évènement envoie des emails aux personnes concernées dans mon “Notification Scheme”.
- Désormais, il faut que je définisse à quel moment je veux déclencher cet évènement.
- Je créé donc une nouvelle règle Automation qui sera amorcée avec l’èvénement “Issue Assigned”
- Mon filtre JQL va cibler les demandes où mon champ “Fournisseur” a la valeur d’un fournisseur spécifique (Atlassian par exemple)
- Et finalement, je vais choisir l’évènement avec les notifications définies pour Atlassian.
Cela fait beaucoup d’étapes mais c’est extrêmement utile lorsque vous souhaitez déclencher des notifications en fonction de la valeur d’un champ dans votre demande par exemple.
Delete Attachments Action
Cette nouvelle action va vous permettre de supprimer des pièces jointes. C’est un contournement au “bulk Edit” pour les pièces jointes 🙂
Pour l’instant je ne l’ai pas encore utilisé. Je ne suis pas très confiante sur le fait de supprimer des éléments dans JIRA automatiquement (hormis s’il s’agit d’un environnement de développement).
Si vous avez des cas d’utilisation où cette action serait très utile au sein de votre entreprise, n’hésitez pas à les partager !
Delete Issue Action
Comme pour l’action précédente, je ne recommande pas l’utilisation de cette action dans un environnement de production. Pour rappel, supprimer une issue est définitif, il vous sera donc difficile de retrouver cette demande à moins d’effectuer une restauration.
N’hésitez pas à vérifier 2 fois votre trigger et filtre afin de supprimer uniquement les éléments que vous ne souhaitez plus sur votre instance !
Vous souhaitez en savoir plus ?
Si ce n’est pas encore fait, vous pouvez jeter un oeil à mon précédent article sur Automation 🙂
Cette extension est gratuite, pourquoi ne pas l’utiliser sur votre instance ?
Je veux l’installer sur mon instance !
Comme toujours, si vous souhaitez poser vos questions, avoir de plus amples informations à propos de cet add-on ou encore partager vos cas pratiques, vous êtes au bon endroit 🙂
