• Article
  • 5.Mar.2013

Déployer JIRA en entreprise partie 2 : Dimensionner JIRA

  • 5.Mar.2013
  • Temps de lecture mins

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.

Ressources complémentaires

Voir toutes les ressources
chevron_right
automatisation

L’automatisation à l’échelle : entre rapidité et agilité

Mettre en place de l’automatisation au service de la transformation demande des ressources et du savoir-faire. Plongez dans le sixième épisode captivant de notre série de podcasts en collaboration avec AirSaas.

 

chevron_right
codir

Le rôle du CODIR dans l’agilité : Une aventure humaine et de conduite du changement

L’impact du comité de direction dans une transformation vers l’Agilité est souvent fort. Découvrez son importance à travers le témoignage de Catherine Croiziers de Lacvivier, DSI de transition au sein du groupe ISAGRI, extrait du podcast CIO Revolution en collaboration avec AirSaas.

chevron_right

Naviguer à travers le changement et l’instabilité économique dans le secteur financier

Dans notre monde en perpétuel mouvement, le secteur financier, essentiel à l’économie mondiale, fait face à des défis et opportunités uniques.