+1-416-273-6883 / +1-855-366-8444
hello@blendedperspectives.com

L'épée de Damoclès - Scripting dans Jira

8 juin 2018

La pente glissante des scripts 

 

L'épée de Damoclès - Scripting dans Jira 1

Chez Blended Perspectives, nous voyons fréquemment des capacités de scripting ajoutées à Jira, Confluence et Bitbucket. Alors que dans Confluence et Bitbucket, l'étendue de ce qu'il est possible de faire avec les scripts est limitée, dans le cas de Jira, les scripts offrent aux administrateurs et aux développeurs de Jira un accès illimité à leur environnement. Le scripting dans Jira permet un accès direct à l'API Java de Jira, libérant ainsi le potentiel de création de solutions commerciales complètes au sein de Jira. D'où l'épée de Damoclès. La légende veut que Dionysius, un roi grec, proposa d'échanger sa place avec Damoclès, un courtisan obséquieux, pour une journée, afin que Damoclès puisse goûter à la bonne fortune. Damoclès accepta rapidement et avec empressement la proposition du roi. Il s'est assis sur le trône du roi, entouré de tout le luxe possible, mais Dionysius a fait en sorte qu'une énorme épée soit suspendue au-dessus du trône, tenue par un seul poil de la queue d'un cheval. Damoclès s'est rendu compte que c'était une responsabilité dont il ne voulait vraiment pas, comprenant qu'avec une grande fortune et un grand pouvoir vient aussi un grand danger. Il en va de même pour les scripts.

Au début, seul l'add-on ScriptRunner offrait des fonctionnalités de script. Aujourd'hui, de nombreux autres modules complémentaires, tels que Jira Misc Workflow Extensions, JSU - Suite Utilities for Jira, Jira Misc Custom Fields et Insight Discovery, se sont lancés dans la création de scripts. Étant donné que nous sommes un partenaire indépendant de Atlassian et que nous n'avons pas d'intérêt direct dans la vente de modules complémentaires, nous adoptons un point de vue purement indépendant sur les avantages et les inconvénients de ces produits.

Dans la plupart des cas, les fonctionnalités offertes par ces modules complémentaires sont si étendues que l'utilisation même du mot "script" est trompeuse. Il peut donner l'impression de permettre des "scripts" mineurs, des morceaux de code innocents qui effectuent de simples actions d'automatisation, sans conséquences majeures. Le fait est que nous pouvons utiliser le scripting pour accéder aux structures internes de Jira, en définissant de nouvelles hiérarchies de classes complètes pour développer des implémentations complexes qui répondent à toutes les exigences commerciales. Malheureusement, comme c'est le cas avec tout autre outil puissant, une utilisation incorrecte peut avoir des conséquences désastreuses, car les scripts nous permettent également d'effectuer des actions assez invasives et très dommageables pour le système. Ainsi, toute la puissance libérée par ces modules complémentaires va bien au-delà de la définition habituelle de ce que suggère le terme "script".

Il peut arriver que les scripts permettent de gagner du temps, mais nous pensons qu'ils doivent être utilisés de manière très judicieuse. Dans cet article, nous examinons en détail les problèmes liés aux scripts, les approches alternatives et, enfin, ce qu'il faut faire si vous vous demandez si vous avez une "bombe à scripts".  

 

Extension des applications Jira

 

Comme mentionné dans le documentation, Jira est très flexible et dispose d'un certain nombre de points d'extension permettant d'interroger les données de Jira ou d'étendre ses fonctionnalités.. Les produits Atlassian sont construits en partant du principe que les entreprises peuvent les étendre. La plate-forme de base est mince, ce qui présente l'avantage évident de ne pas vous faire payer des choses dont la plupart des gens n'ont pas besoin.

La façon la plus élémentaire de mettre en œuvre les extensions de Jira consiste à modifier la configuration, par exemple en définissant de nouveaux flux de travail, champs personnalisés et écrans. Un système de schéma puissant nous permet de modifier l'offre de Jira en un environnement plus personnalisé.

Les modules complémentaires constituent une étape supplémentaire dans l'échelle de personnalisation de Jira. L'achat d'add-ons sur le marché est un moyen simple d'ajouter de nouvelles fonctionnalités. Certains d'entre eux fournissent leur propre interface utilisateur, tandis que d'autres permettent de nouvelles fonctionnalités qui peuvent être intégrées dans les transitions du flux de travail ou fournissent de nouveaux types de champs spéciaux personnalisés. En interne développement de modules complémentaires est une autre façon d'étendre Jira, avec la valeur ajoutée que nous n'avons pas besoin de payer pour des modules complémentaires et que nous pouvons même vendre les modules complémentaires que nous développons dans la base de données de l'UE. Place de marché Atlassian

Les scripts se situent au milieu de ces deux dernières options. L'idée est d'acquérir un module complémentaire qui nous permettra d'utiliser toute la puissance de l'API Jira sans avoir à nous soucier du processus de développement des modules complémentaires. Comme les potentialités de l'API Java sont infinies, elles sont généralement vendues avec la promesse d'être l'outil unique qui les gouverne toutes. Cependant, la création de toute fonctionnalité est une entreprise sérieuse. Il faut un effort ciblé pour coder une idée, et cela ne peut pas non plus être pris à la légère, car il faut des coûts, des compétences et un dévouement pour la maintenance.

 

"Encore une chose"

 

Commencer simplement est simple, peut-être s'agit-il simplement d'ajouter automatiquement une tâche et un ensemble de sous-tâches. Un peu de "colle de code"... et vous avez éliminé une série de clics fastidieux. Si vous évaluez les possibilités de l'API Java de Jira, vous vous rendrez compte qu'elles sont vastes. Vos possibilités sont infinies ! Les clients sont généralement immédiatement satisfaits et le fournisseur de services a tenu ses promesses.

Cela peut se manifester de multiples façons. Dans certaines organisations, les visionnaires de l'entreprise font pression pour obtenir plus. Quelque temps plus tard, d'autres scripts arrivent. Des mois plus tard, les clients reviennent et en redemandent. Votre code de colle s'est étendu. Il s'interface avec d'autres codes. Vous devez trouver un moyen de le documenter. Vous n'êtes plus un administrateur, mais aussi un programmeur, un architecte/concepteur et un gestionnaire de produits.  

 

Organiser de manière standard

 

L'extension d'un système distribué tel que Jira nécessite de saupoudrer du contenu à travers les différents éléments (flux de travail, comportements, écouteurs d'événements, services d'escalade, etc.) ). Depuis au moins 10 ans, Atlassian fournit aux programmeurs une structure à cet effet. Les normes, quant à elles, s'appuient sur Java, avec des directives solides qui existent depuis une dizaine d'années. Ces normes et directives permettent de tester les performances, de déboguer, de documenter et d'automatiser. Ainsi que la rigueur autour des constructions. 

L'interface utilisateur de Jira ne dispose pas d'un moyen simple de contrôler tous les scripts. actuellement dans le système.  ScriptRunnerLes versions ultérieures fournissent une Registre des scripts qui aide à localiser les scripts. Cependant, cette fonction peut échouer dans les grandes instances ou lorsque trop de scripts sont utilisés. Même en utilisant la fonction de registre de scripts fournie par ScriptRunnerle code est toujours dispersé à travers plusieurs structures, ce qui rend difficile le suivi du script en production. Le fait que plusieurs développeurs créent les scripts n'aide pas dans ce sens. Pour le reste des modules complémentaires fournissant des fonctionnalités de script, le cas est encore pire. Par exemple, lorsque vous utilisez Jira Misc Custom Fields, les scripts sont les suivants situé dans la description des champs personnalisés, ce qui n'est pas du tout un endroit intuitif pour stocker un morceau de code.

Une fois que les scripts sont en production, lorsqu'ils échouent, ils n'affichent généralement aucun avertissement de problème dans l'interface utilisateur. La plupart des erreurs se produisent silencieusement et ne sont détectées que dans les journaux ou lorsque des incohérences dans les données révèlent que les scripts ne fonctionnent pas comme prévu. Les journaux de Jira, étant dans un serveur de production, ne sont pas facilement accessibles par les utilisateurs non administrateurs.

Dans la plupart des organisations, le rôle d'administrateur Jira n'inclut pas nécessairement des compétences en développement. Les administrateurs Jira sont confrontés à l'évaluation de scripts dont ils n'ont pas forcément une compréhension totale, ce qui est encore plus problématique lorsque non seulement des compétences en Java/Groovy sont requises mais aussi une bonne compréhension de l'API Java Jira. Il n'est pas juste d'attendre d'un administrateur Jira qu'il valide un morceau de code destiné à la production. Cela devrait être le résultat d'un processus d'examen et d'approbation par les pairs, comme dans toute autre activité de développement de logiciels.

 

Actions potentiellement dommageables

 

Si l'utilisation de l'API REST de Jira est relativement sûre, l'API Java offre un accès complet à de nombreux domaines où une utilisation abusive, accidentelle ou intentionnelle, peut causer des dommages considérables. Voici quelques-unes des actions qui peuvent causer des dommages :

  • Effectuer des actions de sortie (création, mise à jour, suppression) en contournant les autorisations de Jira.
  • Créez et mettez à jour les liens entre les numéros, en rompant la cohérence.
  • Exécuter JQL en ignorant les limites du nombre de résultats (impact sur les performances).
  • La définition directe des valeurs des champs personnalisés rompt la cohérence, ignore l'historique des problèmes et affecte l'index Jira.
  • Créez, mettez à jour et supprimez des comptes d'utilisateur en masse.
  • Exécuter des actions en se faisant passer pour un autre utilisateur.

Chacune de ces actions peut être effectuée dans un grand nombre d'éléments, par exemple la suppression de tous les numéros en une seule fois par accident ou la désactivation de tous les comptes d'utilisateur dans une mise à jour en masse erronée. 

L'épée de Damoclès - Scripting dans Jira 3

 

Problèmes de maintenance du code

 

L'utilisation de le site ScriptRunner place les administrateurs de Jira dans le même champ que les développeurs de modules complémentaires, donc ils sont forcés d'utiliser les mêmes procédures et sauvegardes que celles utilisées dans tout autre projet de développement de logiciels. Développeurs d'add-ons Jira sont censés de mettre à jour le code de leurs modules complémentaires à chaque fois qu'une nouvelle version de Jira est publiéà la suite des modifications apportées à l'API Java. Atlassian annote les classes et méthodes dépréciées pour signaler leur disparition dans les prochaines versions et pour encourager les développeurs à adopter les nouvelles options disponibles. Dans le cas où ces dépréciations sont ignorésà terme, le code échouera avec les futures mises à jour de Jira. Atlassian annonce également les changements à venir à l'adresse https://developer.atlassian.com/jiradev/latest-updates/jira-eap-releasesoù les multiples "Préparation de Jira 7.x" peut être trouvé avec des informations détaillées sur ces changements.

Les développeurs de ScriptRunner prennent soin de mettre à jour leur code et de publier la nouvelle version compatible avec la nouvelle version de Jira, donc toute action intégrée que le ScriptRunner fournit devrait être ok. Les problèmes se situent au niveau du code personnalisé qui peut se briser dans la nouvelle version de Jira en raison de changements dans l'API Java. Il est très courant de trouver du code en production utilisant des classes dépréciées, ce qui constitue un risque pour la stabilité du système.

Étant donné que la plupart des organisations disposent d'une procédure stricte d'examen et d'approbation avant d'installer un nouveau module complémentaire, il est logique de mettre en place une procédure similaire pour les scripts ajoutés au système. Dans le cas de nouveaux modules complémentaires, ils sont généralement largement testés par les développeurs et les problèmes sont signalés par la communauté Atlassian, ce qui n'arrive pas avec les scripts personnalisés développés en interne, ce qui rend encore plus important la mise en place d'un examen et d'une approbation appropriés.

 

Les défis de la réutilisation du code

 

ScriptRunner incorpore les scripts dans Jira de deux manières : les scripts en ligne et les références au système de fichiers. Les scripts en ligne sont définis dans l'interface web, en collant le code que nous espérons avoir développé et testé dans un IDE approprié ou, malheureusement, un cas très fréquent, en collant le code que nous avons trouvé sur Internet.

Lorsque l'on utilise des scripts en ligne, on ne peut pas importer les classes utilitaires définies dans d'autres scripts. Dans ce cas, le code est stocké dans la base de données Jira, soit dans des tables Active Object, soit dans la définition du workflow. C'est un inconvénient majeur de cette méthode qui entraîne une duplication considérable du code. La maintenance du code est également affectée car lorsqu'une modification d'une classe ou d'une fonction utilitaire dupliquée est nécessaire, elle doit être modifiée dans tous les scripts où elle a été dupliquée. Cette modification est effectuée à l'aide de l'interface graphique de Jira, principalement dans l'éditeur de flux de travail, ce qui prend beaucoup de temps et est source d'erreurs.

L'utilisation de scripts dans le système de fichiers nous permet de définir des classes utilitaires et de les importer dans notre code, avec des avantages évidents pour la maintenance, la réutilisabilité et la cohérence du code. Cette méthode présente toutefois un inconvénient : elle nécessite un accès direct au système de fichiers, ce qui peut constituer un obstacle dans de nombreuses organisations pour des raisons de sécurité. D'un autre côté, cela peut être un avantage du point de vue de la sécurité et de la gouvernance, où seul le code approuvé entre en production en suivant des canaux définis. Le code dans le système de fichiers n'est pas visible depuis l'interface graphique de Jira, seulement une référence à l'emplacement du script. Le fait de conserver le code dans un dépôt git et de mettre en œuvre les procédures de traçabilité des modifications peut atténuer ce problème. L'accès de Jira à l'interface d'administration n'est pas suffisamment granulaire pour empêcher l'administrateur de Jira d'accéder aux scripts. Le fait de conserver les scripts dans le système de fichiers permet de sécuriser le code et de définir des autorisations dans les projets et dépôts Bitbucket afin de n'autoriser que les accès autorisés au code.

 

Déploiement et limitation de l'interface utilisateur Jira pour les changements simultanés 

 

Les scripts situés à plusieurs endroits peuvent dépendre les uns des autres. L'utilisation de l'interface graphique pour insérer le script en ligne rend difficile la mise à jour de plusieurs scripts à la fois. Le processus même de mise à jour des structures contenant les flux de travail est différent. Certaines modifications peuvent être déployées et appliquées ultérieurement, d'autres sont immédiates. Voici quelques exemples de ce problème :

  • Les modifications du flux de travail sont appliquées lors de la publication du flux de travail, dans certains cas, cela nécessite la création d'une copie du flux de travail et l'application d'un nouveau schéma de flux de travail.
  • Les changements d'écran se font immédiatement (pas de bouton de sauvegarde !)
  • Les écouteurs sont une configuration globale, attachée aux projets en définissant une portée, qui peut être dangereusement large et affecter tous les projets à la fois.
  • Les scripts dans les comportements peuvent avoir un mappage complexe de projets, de types de problèmes, de champs et de transitions de flux de travail.

Avec les flux de travail et les écrans, les changements peuvent être échelonnés en utilisant des schémas et en réappliquant les schémas aux projets associés. Cependant, la réapplication d'un schéma peut prendre un certain temps, en fonction du nombre de problèmes, et pendant ce temps, le statut du projet est instable. Si un script est en cours d'exécution alors que le changement est déjà appliqué dans certaines zones et pas encore dans d'autres, nous pouvons obtenir des résultats inattendus.

L'utilisation de scripts dans le système de fichiers atténue ces problèmes dans une certaine mesure, car ils permettent le déploiement de plusieurs scripts à la fois, en garantissant qu'ils sont cohérents entre eux et qu'il n'existe aucune fenêtre instable. Mais cette cohérence ne s'appliquera qu'aux scripts et n'empêchera pas les incohérences avec les structures Jira connexes incluses dans la solution mise en œuvre. Tout cela se résume à la nécessité de disposer de temps d'arrêt pour la maintenance lorsque la complexité de la solution basée sur des scripts augmente.  

 

Développement de modules complémentaires par rapport à ScriptRunner

 

Chaque fonctionnalité que le ScriptRunner fournit est possible à réaliser avec un add-on personnalisé. L'API Java est la même. ScriptRunner fournit uniquement l'interface permettant d'insérer les scripts dans Jira, ce qui permet d'éviter de construire un module complémentaire.. Un commentaire différent peut être fait à propos de la fonction "Comportements", qui repose largement sur JavaScript, cependant, les Comportements sont en fait un produit différent livré avec le module complémentaire ScriptRunner (en fait, c'était un module complémentaire séparé à ses débuts). Il est vrai que ScriptRunner fournit également de nombreuses fonctionnalités intégrées, mais dans ce cas, il ne s'agit pas de fonctionnalités de "scripting", mais de fonctionnalités similaires à celles que les add-ons non scripting fournissent, comme l'usurpation d'identité d'un autre utilisateur, la copie des valeurs des champs personnalisés, etc..

Un add-on personnalisé est un produit plus packagé, qui peut être désactivé d'un coup s'il pose des problèmes. Dans ce cas, tous les flux de travail utilisant les structures créées par le module complémentaire (conditions, validateurs et flux de travail) ne fonctionneront pas comme prévu, mais c'est également un problème lorsque l'on désactive un script ScriptRunner défectueux. Un module complémentaire Jira n'est pas très différent de tout autre projet de développement Java. Il peut être correctement documenté et les meilleures pratiques de développement de logiciels appliquées, ce qui est difficile à réaliser avec ScriptRunner, où une multitude de scripts sont dispersés dans de nombreuses structures de configuration Jira. Et une fois que vous avez créé un module complémentaire, les autres sont similaires, de sorte que l'effort s'adapte très bien à l'ajout de nouvelles fonctionnalités.

Le débogage et le dépannage sont également améliorés lorsque vous développez votre propre module complémentaire. Vous n'aurez pas à traiter avec une partie intermédiaire, à chercher pourquoi le code que vous utilisez n'est pas traduit par le module complémentaire de script dans le résultat attendu sur l'API Java de Jira. Lorsque vous développez votre propre module complémentaire, vous pouvez utiliser la hiérarchie de classes bien documentée de l'API Jira et savoir exactement à quoi vous attendre, sans boîte noire entre les deux. En bref, vous maîtrisez l'ensemble du processus.

 

Java contre Groovy

 

Il n'est pas tout à fait exact de considérer ScriptRunner et le reste des modules complémentaires de script comme de simples outils de scriptage Groovy. Lorsque nous utilisons Groovy pour mettre en œuvre une solution, nous utilisons des objets et des paquets importés de l'API Java Jira. La souplesse de typage qu'offre Groovy et la flexibilité de la syntaxe peuvent être une arme à double tranchant, si ce n'est, bien sûr, l'épée de Damoclès ! S'il nous permet d'aller plus vite et de ne pas nous préoccuper des types que les objets doivent avoir, il rend plus difficile la détection des erreurs et des fautes qui peuvent se produire sans avertissement. Lorsqu'une solution devient trop compliquée, la complexité de la gestion de tous les scripts impliqués augmente. 

En fin de compte, nous sommes censés utiliser un module complémentaire de script pour accéder à l'API Java de Jira. Mais l'API Java de Jira est développée en Java, pas en Groovy ! L'utilisation de Groovy ne fera que vous empêcher d'être en mesure d'emballer ce code plus tard dans un seul add-on. Une fois que vous avez des centaines de milliers de scripts utilisant la syntaxe Groovy, les formaliser en syntaxe Java est un effort fastidieux, probablement plus important que le développement initial. L'utilisation de Groovy ne fera que vous rendre éternellement dépendant du module complémentaire de scripting. L'utilisation de Java a l'avantage supplémentaire qu'il y a beaucoup plus d'exemples et de documentation pour Java que pour Groovy partout sur Internet. 

 

Conclusions

 

Le cycle de vie de l'utilisation des scripts dans de nombreuses organisations montre qu'il commence de manière simple, avec des scripts de base destinés à combler les lacunes des fonctionnalités prêtes à l'emploi de Jira. Cependant, au fur et à mesure que l'on découvre les possibilités d'utiliser directement l'API java de Jira, il devient difficile de résister à la tentation de développer des implémentations encore plus complexes en utilisant cette approche.

Au lieu de développer un module complémentaire personnalisé dès le départ, les mêmes ressources sont investies dans la création de centaines ou de milliers de scripts avec le calvaire de maintenance et d'administration correspondant. Très vite, il y a trop de scripts à gérer.

La complexité des solutions peut être estimée en fonction de la taille de votre organisation. Si l'on sait dès le départ qu'un simple script ne suffira pas, il est plus logique de développer un module complémentaire en interne. Si nous nous enfonçons de toute façon dans des eaux profondes, l'utilisation d'un script complémentaire causera probablement plus de mal que de bien. Le développement de modules complémentaires peut sembler complexe, mais nous n'échapperons pas à la complexité en utilisant des scripts. Au contraire, nous allons créer plus de complexité.

Enfin, si nous savons que la solution dont nous avons besoin est assez simple, alors il peut très bien y avoir un moyen de faire de telles choses sans script. Donc, si vous avez des doutes sur la quantité de colle de code que vous pouvez avoir ou si vous êtes préoccupé par l'impact sur la stabilité de votre système, appelez-nous pour une évaluation gratuite de votre installation Jira. Nous pouvons aide,  contactez-nous aujourd'hui !

- Blended Perspectives est le plus grand partenaire de solutions Atlassian au Canada, offrant des services de conseil, d'hébergement géré, d'installation, de migration de données, d'optimisation des performances et de formation certifiée Atlassian. Nous disposons d'une expertise approfondie de tous les produits Atlassian, avec des experts certifiés couvrant l'ensemble du cycle de vie du SDLC, Service Desk et le support d'applications commerciales plus larges. Fondée en 2007 après des années d'expérience au service de clients au Canada, en Europe, aux États-Unis et en Australie, la mission de Blended Perspectives est de permettre aux entreprises de libérer la puissance de leurs équipes et d'exploiter le véritable potentiel de leur activité grâce à des outils et des processus améliorés.

fr_CAFR
Partager ceci