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

Valiantys Enterprise Days : Forrester, Atlassian, RATP, Forterro, ADP, et bien d'autres... vous donnent les clés du travail d'équipe digital et intelligent. Découvrez l'agenda !

valiantys-logo
Back

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

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.

Cutted Triangle

Inscrivez-vous à notre newsletter

Demande enregistrée ! Demande en cours... Ceci n'est pas un email Une erreur s'est produite

Conformément à notre politique de confidentialité, nous nous engageons à respecter vos données personnelles.

Contactez-nous

Nos consultants certifiés Atlassian seront ravis de vous répondre.

Rejoindre Valiantys

Nous sommes en train de construire un équipe extraordinaire. Vous en êtes ?

Suivez-nous

Nous utilisons des cookies pour le fonctionnement de ce site, pour améliorer son utilisation, personnaliser votre expérience et réaliser des statistiques de visite. Vous pouvez gérer les paramètres et choisir d’accepter ou non certains cookies durant votre navigation. Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Paramètres de confidentialité

Afin de faciliter votre navigation et de vous apporter le meilleur service possible, nous utilisons des cookies pour améliorer le site aux besoins des visiteurs, notamment selon la fréquentation.  Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Recaptcha

Google reCAPTCHA est un système conçu pour distinguer les humains des ordinateurs, de telle sorte que les bots soient incapables de remplir les formulaires de manière malveillante au nom d’un être humain.

Analytics

Utilisé pour envoyer des données à Google Analytics sur le périphérique et le comportement du visiteur. Suit l'internaute à travers les appareils et les canaux de marketing. Utilisé par Google Analytics pour diminuer radicalement le taux de requêtes. Enregistre un identifiant unique utilisé pour générer des données statistiques sur la façon dont le visiteur utilise le site.

LinkedIn

Cookies pour une publicité ciblée : Ces cookies peuvent être mis en place au sein de notre site Web par nos partenaires publicitaires. Ils peuvent être utilisés par ces sociétés pour établir un profil de vos intérêts et vous proposer des publicités pertinentes sur d'autres sites Web. Ils ne stockent pas directement des données personnelles, mais sont basés sur l'identification unique de votre navigateur et de votre appareil Internet. Si vous n'autorisez pas ces cookies, votre publicité sera moins ciblée.

Cookies "réseaux sociaux" : Ces cookies sont activés par les services proposés sur les réseaux sociaux que nous avons ajoutés au site Web afin de vous donner la possibilité de partager notre contenu avec votre réseau et vos connaissances. Ils nous permettent également de suivre votre navigation sur d’autres sites Web et d’établir un profil de vos intérêts. Cela peut avoir un impact sur le contenu et les messages affichés sur les autres sites Web que vous consultez. Si vous n'autorisez pas ces cookies, il se peut que vous ne puissiez pas utiliser ou visualiser ces outils de partage.