Cet article est le deuxième d’une série de trois articles consacrés à la gestion d’instances JIRA dans une entreprise. Ils exploitent les ressources mises à disposition par Atlassian (sur cette documentation notamment) ainsi que notre expérience d’experts Atlassian de longue date.
L’évolution de JIRA en entreprise
Lorsque l’on installe JIRA, c’est souvent pour répondre à un use case spécifique pour une équipe ou un service particulier. Suite à cela, il est très courant que JIRA se déploie de lui-même dans l’entreprise chaque fois qu’un service supplémentaire rejoint l’outil, que l’entreprise acquiert une entreprise qui possédait déjà JIRA ou encore que l’on implémente un nouveau use case non prévu initialement. Il est important de réfléchir au dimensionnement de JIRA avant son déploiement, afin d’anticiper au maximum ces différents cas.
Dans un premier temps, il est nécessaire de s’interroger sur le nombre d’instances JIRA nécessaires à couvrir l’ensemble des besoins. Par exemple, on peut avoir besoin d’une instance publique ouverte à ses clients (donc accessible via internet) où on ne souhaitera pas stocker ses données internes pour des raisons de sécurité. Certains use case dans JIRA pourront également nécessiter l’acquisition d’une licence supplémentaire. En effet, plusieurs éléments dans JIRA sont communs à tous les projets : les utilisateurs, les groupes, les rôles, les priorités, les plugins, le code source de l’application, le nombre de champs personnalisés, etc. Le fait de rassembler sur une même instance un grand nombre de use case totalement différent peut vite devenir confus pour les utilisateurs, et même les administrateurs.
Cela dit, la multiplication d’instances JIRA dans une entreprise pose aussi des problématiques importantes :
- Chaque instance JIRA requiert une licence et un ensemble d’environnements (voir article précédent)
- Chaque plugin payant requiert une licence par instance
- Les utilisateurs sont confrontés à plusieurs URL et il n’est pas forcément évident de trouver un découpage logique sur une instance surchargée
- Les administrateurs doivent maintenir plusieurs plateformes au lieu d’une seule
- La gestion des utilisateurs est plus complexe (dans le cas où l’on ne dispose pas de Crowd ou d’annuaire LDAP)
- Il n’est pas possible d’exporter simplement de la configuration d’une instance à une autre (sauf les workflows via le workflow sharing plugin)
- Les montées de version devront être effectuées instance par instance
A vous donc de trouver le juste milieu, en tenant compte également des problématiques techniques décrites ci-dessous. Il est également possible de rassembler deux instances existantes (dans le cas d’un rachat de société ou pour des raisons de coût notamment) en utilisant l’import de projet JIRA.
Recommandations techniques
L’architecture technique de votre plateforme JIRA doit être capable d’évoluer lorsque c’est nécessaire, afin de toujours garantir la sécurité des données et des performances acceptables pour les utilisateurs. Sachant que chaque instance JIRA doit contenir au maximum 200 000 demandes (jusqu’à JIRA 5.0 inclus) ou 500 000 demandes (à partir de JIRA 5.1 inclus) selon les préconisations de l’éditeur, on dispose déjà d’un critère déterminant pour séparer une instance en deux (ou plus).
Afin de dimensionner correctement l’architecture de JIRA, il faut au préalable estimer (depuis un système existant si possible) :
- Le nombre d’utilisateurs fréquents et occasionnels
- Le nombre de demandes initial
- Le nombre de nouvelles demandes par mois
A partir de ces résultats, vous pourrez vous baser sur les recommandations de l’éditeur pour dimensionner vos serveurs.
Pour anticiper les changements sur votre architecture, Atlassian met à notre disposition un plugin appelé Data Generator. Ce plugin vous permettra de remplir votre instance existante de données fictives correspondant à votre volumétrie estimée dans le futur afin d’y exécuter des tests de performance.