Vos imports/exports de workflows, (bientôt) une partie de plaisir


Publié par
Paul ROCHE

18 juin 2012

Dans la dure vie d’un summiter, il est parfois difficile de faire son choix face à l’abondance de l’offre des conférences. Si certaines sont de grandes messes, comme les keynotes des deux fondateurs d’Atlassian (Steve Jobs a bien assuré sa descendance avant de disparaître :) ), d’autres sont beaucoup plus confidentielles, et le moins que l’on puisse dire, c’est que leurs intitulés sont parfois assez loufoques.

Ce vendredi après-midi, 3:00 PM, une ambiance de fin summit régnait dans les stands… En consultant le planning des conférences, je m’étonne de l’intitulé de l’une d’entre elles: « Workflow Magic ». Curiosité éveillée, pas un chat sur le stand, ni une ni deux je file m’installer très gracieusement dans un des poufs du premier rang de la salle « JIRA everywhere » (ça s’invente pas!).

Jonathan Doklovic est à la barre, il est connu entre autre pour être le développeur du Workflow Designer de JIRA.

Il a aujourd’hui choisi de nous parler des difficultés de porter les workflows au format XML d’une instance JIRA à l’autre. Il commence par un inventaire des points bloquants: les ids non concordants des états, les écrans ou custom fields qui n’existent pas, les fonctions de workflows d’un plugin tiers qui viennent à manquer… bref tout y passe et là j’ai envie de lâcher: « merci Jon de me rappeler mon quotidien de paramétreur JIRA alors que j’étais jusque là dans un état de plénitude siliconesque ». Mais je me retiens en me disant: « s’il en parle, c’est peut être qu’il a une solution… ».

Et LA solution viendra bien… elle prendra pour tout dire la forme d’une vidéo de présentation du JIRA Workflow Sharing Plugin, qui aura littéralement déclenchée l’hystérie de l’assistance, prête à communier (les events Atlassian sont pourtant tout ce qu’il y a de plus païen je vous assure) comme pour exorciser tous les maudits workflows de la création.

La solution s’appuie sur la génération d’une archive qui embarque, en plus du workflow itself en XML:

  • des copies de tous les plugins (JARs) dont les classes seraient mentionnées dans le backup XML
  • les déclarations de ces mêmes plugins (JSON)
  • les déclarations de tous les custom fields (JSON) du backup XML
  • les déclarations de tous les screens (JSON) du backup XML
  • une éventuelle mise en forme dans le workflow designer (on appréciera de ne pas avoir à refaire tout ce travail assez fastidieux…)
L’importation de ce package dans votre nouvelle instance sera donc capable de prendre en charge:
  • le mapping des ids d’états, custom fields et écrans existants sous le même nom
  • la création de ceux qui n’existeraient pas
  • la proposition d’installer des plugins manquants (en s’assurant sur la Market place de leur compatibilité avec votre version JIRA)
  • un avertissement pour tous les plugins pour lesquels aucune une version compatible n’a pu être trouvée
  • la suppression du back-up XML de toute fonction de workflow qui solliciterait un plugin manquant
  • un roll-back de toutes les opérations (installations de plugins ou changement dans le paramétrage) si l’importation venait à échouer
  • la notification de toutes les modifications apportées entreprises (par un report et des mails envoyés à tous les admins de l’instance).

Bien sûr il y aura certainement quelques erreurs et peut-être des cas non gérés (Par exemple, il n’a été nulle part évoqué la gestion des groupes et rôles qui pourraient manquer dans les conditions de wf…), mais on ne peut que saluer l’effort d’Atlassian d’enrichissement de cette fonctionnalité qui était restée statique depuis bien longtemps.

Cette évolution s’inscrit plus largement dans une ambition d’intégrer ce nouveau format de workflow dans la Market Place: au même titre que les plugins (qu’il faut maintenant appeler add-ons soit dit en passant 😉 ), vous pourrez installer des workflows types mis à disposition comme extension (exemple d’un wf service desk ITIL).

Merci Jonathan!!!