Pourquoi devez-vous faire des montées de version régulières de vos instances JIRA


Publié par
Leo Kervizic

19 avril 2017

Réaliser une montée de version revient souvent à se motiver pour faire du sport. Il y aura toujours une bonne raison pour ne pas en faire, même si vous savez que vous devriez !

Les administateurs Atlassian et les décisionnaires se disent :

  • « Ce n’est pas encore nécessaire, ça marche bien en ce moment »
  • « Nous monterons de version uniquement quand le besoin de nouvelles fonctionnalités se fera sentir »
  • « Je n’ai pas le temps de gérer ce type de projet, cela va prendre trop de temps ».

Comment je sais tout ça ? J’étais un de ces admins JIRA ! Mais je sais que je ne suis pas le seul à le penser, c’est le cas dans de nombreuses sociétés.Pourtant vous savez que vous avez tout à y gagner de le faire

Et un jour, un client arrive et demande la dernière fonctionnalité ou l’ajout d’un nouvel add-on. Soudain, cela devient urgent de faire cet upgrade de 2 ou 3 versions majeures. L’opération prend du temps, on découvre des bugs, des problèmes dans les workflows ou des utilisateurs trop nombreux. Naturellement, ces opérations vont prendre du temps et le client ne sera pas satisfait car des mois s’écouleront avant l’arrivée de ses fonctionnalités tant attendues.

Avec un peu d’effort, cela peut être différent. Upgrader son JIRA ou son Confluence peut se faire rapidement et sans stress. Il faut juste s’organiser pour faire des montées de version régulièrement. Les solutions Atlassian sont Agiles. Il est donc possible de les mettre à jour régulièrement et sans effort.

Il faut donc prévoir chaque année, 1 à 2 upgrade de son application. La première fois est souvent difficile, la deuxième un peu moins jusqu’à ce que cela devienne une formalité. Pour en arriver là, il y a quelques précautions à prendre :

  • Communiquer avec vos utilisateurs régulièrement. Au début, ils sont réticents, ils ont peur d’être gênés dans leur travail. Avec le temps, la confiance s’installera car les montées de version précédentes se seront très bien déroulées et vous leur aurez apporté de nouvelles fonctionnalités rapidement.
  • Identifier les périodes non-critiques de l’entreprise. Rien de pire qu’une application JIRA indisponible au moment de finaliser un projet important ou que le site web de l’entreprise soit indisponible au moment du lancement d’une campagne marketing.
  • Avoir un environnement de test, copie de la production. Cela ne prend pas de licence supplémentaire.
  • Vérifier que votre licence n’a pas expirée. Cela bloquera la montée de version.Si vous pensez que la gestion des licences est compliquée, peut être que déléguer cette tâche vous plairait ?
  • Vérifier la compatibilité de vos add-ons.
  • Lister les personnalisations que vous avez apportées à votre application. Ceci facilitera la définition de votre cahier de test. Avec l’expérience, vous saurez quels sont vos fonctionnalités critiques. Généralement, nous préconisons de réduire le spécifique et d’utiliser les add-ons.

Dans ma précédente entreprise, j’ai réussi avec beaucoup de patience et d’efforts à mettre en place un process d’upgrade régulier. Mon premier cauchemar était une montée de version depuis JIRA 3.13 vers JIRA 5.1.4. Nous avions oublié le renouvellement de la maintenance et réalisé nous-même une fusion d’instance. Le projet nous a pris six mois car nous avons ajouté un environnement de test, rédigé les procédures d’upgrade, de merge et de test, réalisé des développements spécifiques pour le merge, géré les contraintes des add-ons, … Le déploiement, quant à lui, a duré 2 jours…

L’année suivante, nous sommes passés de JIRA 5.1.4 à JIRA 6.1. Cela fut relativement plus rapide avec cette fois un mois de travail qui nous a demandé de tester/corriger 100 scripts développés en interne et ensuite une journée pour le déploiement. Six mois plus tard, voici venu le moment d’une nouvelle montée de version pour passer à JIRA 6.4. Cela a été une formalité ! Nous l’avons réalisée en à peine cinq jours. L’upgrade suivant vers JIRA 7.1 et l’ajout de Confluence dans le process s’est très bien déroulé. Aucun problème pour JIRA et des bugs techniques mineurs pour Confluence.

Grâce à cette politique de montée de version régulière, nos applications ne sont plus un frein à l’innovation. Nos clients sont des utilisateurs heureux car ils ont l’opportunité d’adapter leurs outils à leur méthode travail et non de s’adapter à leurs outils pour travailler.

Si vous pensez avoir besoin d’accompagnement pour vos montées de version, contactez Valiantys en cliquant sur le bouton ci-dessous.