13 étapes pour réussir votre

passage à JIRA 7

-Le Kit de montée de version-

Johann Bertrand NG

Consultant AtlassianDéveloppeur Freelance

Full Stack JavaScript

Jean-Baptiste MBA

Consultant AtlassianFondateur de JIRA Club

www.jira-club.net

Avant propos

Ce mémo en 13 points reprend les 13 préconisations suggéréespar JIRA Club pour sécuriser vos montées de version JIRA. Enparticulier, votre passage à JIRA 7.

Il s’appuie sur l’expertise de consultants expérimentés. Johann etmoi avons en effet accompagné plus de vingt entreprises enFrance, et à l’étranger, autour des problématiques Atlassian aucours des 5 dernières années.

Cet ouvrage n’a toutefois pas la prétention de se substituer à unequelconque prestation de conseil ou d’assistance technique sur lesujet. Il s’agit avant tout d’un guide conçu pour aider nos clients àmieux appréhender les problématiques liées aux montées deversion JIRA.

Enfin, nous sommes impatients de recueillir vos questions etréactions vis-à-vis de cet E-book. N’hésitez pas à nous les faireparvenir à l’adresse contact@jira-club.net. Nos équipes se ferontun plaisir de vous répondre.

Excellente lecture,L’équipe JIRA Club

• Définissez vos scénarios de testEtape 1

• Consultez la documentationEtape 2

• Mettez à niveau vos licences et extensionsEtape 3

• Choisissez votre procédureEtape 4

• Arrêtez l’instance JIRAEtape 5

• Sauvegardez les répertoires JIRAEtape 6

• Sauvegardez vos spécificitésEtape 7

• Sauvegardez votre base de donnéesEtape 8

• Effectuez la montée de versionEtape 9

• Reportez vos spécificitésEtape 10

• Redémarrez l’instanceEtape 11

• Déroulez les scénarios de testEtape 12

• Effectuez un roll-backEtape 13

Sommaire

1. Définissez vos scénarios de test

Quelles sont les points sensibles de votre installation JIRA ? Quelles en

sont les fonctionnalités les plus critiques ? Ce sont ces aspects que vous

devez tester en priorité.

En m’appuyant sur mes plus récentes expériences, je peux vous livrer

ici, pêle-mêle, les éléments qui posent généralement problème chez

mes clients lors des montées de version:

1. Le reverse proxy

2. La connexion des utilisateurs

3. L’intégration JIRA/Confluence

4. Le fonctionnement des add-ons

5. Les filtres et les tableaux de bord

7. Les projets clés

8. Les autorisations

Cet aspect est traité en détail dans notre article de blog dédié aux

scénarios de test. Vous pouvez le consulter ici : http://www.jira-

club.net/fr/montee-de-version-jira-le-scenario-de-test

2. Consultez la documentation

Quelque soit votre niveau d'expérience et de connaissance des outils

Atlassian, vous aurez toujours besoin de consulter certains documents

avant de procéder à une quelconque montée de version JIRA. Il s’agit

notamment :

- Des release notes

- Des upgrades notes

- Et de la base de connaissance Atlassian

Les release notes vous permettent d’être au fait des spécificités de la

version que vous êtes sur le point de déployer.

Les upgrade notes vous permettent d’être au fait des particularités de

la montée de version que vous vous apprêtez à réaliser.

Enfin, la base de connaissance Atlassian vous permet de capitaliser

sur le retour d’expérience de ceux qui, de par le monde, vous ont

précédé dans cette montée de version.

Ces 3 sources d’information sont traitées plus en détail dans notre

article de blog dédié à la documentation des montées de version JIRA

: http://www.jira-club.net/fr/montee-de-version-jira-la-documentation

3. Mettez à niveaux vos extensions et leurs licences

Avant d'aller plus loin dans votre procédure de montée de version,

vous devez vous assurer que :

• Votre licence est encore couverte par le contrat de maintenance Atlassian

• Les extensions que vous utilisez sont compatibles avec votre version cible de

JIRA

• Vos extensions sont encore couvertes par les contrats de maintenance associés

Procéder à une montée de version alors que votre licence JIRA n’est

plus couverte par un contrat de maintenance peut en effet conduire à

une erreur bien connue :

https://confluence.atlassian.com/display/JIRAKB/After+upgrade+JIRA

+shows+500+error+page+with+message+User+has+no+unique+key+

mapping

De même, votre montée de version sera problématique si vous utilisez

des extensions incompatibles avec la version cible que vous êtes sur le

point d’adopter.

Vous pouvez utiliser la procédure décrite ici pour identifier les

extensions incompatibles avec votre version cible :

https://confluence.atlassian.com/display/UPM/Checking+add-

on+compatibility+with+application+updates

4. Choisissez votre procédure de montée de version

La documentation officielle d’Atlassian préconise 3 procédures de

montée de version différentes en fonction de vos impératifs de

production. Nous les avons résumées dans le tableau ci-dessous.

Vous pouvez consulter les documentations officielles d’Atlassian sur les

montées de version JIRA ici :

https://confluence.atlassian.com/jira/upgrading-jira-185729508.html

Quelle méthode choisir

Quel mode opératoire Quelles conditions En savoir plus

Mise à jour avec Roll-back

Suivre la procédure préconisée par Atlassian

Environnementcritique – Impossible d’envisager un arrêt de la production

https://confluence.atlassian.com/jira/upgrading-jira-with-a-fallback-method-311920141.html

Mise à jour rapide Utiliser l’assistant d’installation et de mise à jour fourni par Atlassian

3h d’arrêt de production envisageable

https://confluence.atlassian.com/jira/upgrading-jira-using-a-rapid-upgrade-method-312738529.html

Mise à jour manuelle Utiliser le fichier archive au format WAR + la procédure manuelle fournie par Atlassian

Version de JIRA antérieure à JIRA 4.2.x

https://confluence.atlassian.com/jira/upgrading-jira-185729508.html

5. Arrêtez l’instance JIRA

La procédure de démarrage et d'arrêt de JIRA dépend du système

d'exploitation que vous utilisez et de la manière dont vous l'avez

installé.

Si vous utilisez un système de type Linux :

• Connectez vous en tant que root ("sudo -s", sous Debian)

• Rendez-vous dans le répertoire de l'exécutable JIRA (Généralement

"/opt/Atlassian/JIRA/bin")

• Exécuter la commande d'arrêt de l'instance ("./stop-jira.sh")

Si vous utilisez un système de la famille Windows :

• Rendez-vous dans le répertoire de l’exécutable JIRA (Généralement "C:\Program

Files\Atlassian\JIRA\bin")

• Exécutez la commande d’arrêt de l’instance "stop-jira.bat")

Si vous utilisez plutôt un système de type Mac OS X, sachez qu’il s’agit

d’une configuration qui, par défaut, n’est pas supportée par Atlassian.

Vous trouverez néanmoins des informations utiles sur le sujet ici :

https://confluence.atlassian.com/display/JIRA044/Configure+JIRA+as+s

ervice+on+Mac+OS+X

6. Sauvegardez les répertoires de données et d’installation de JIRA

Le répertoire d'installation est le répertoire dans lequel sont stockés

l'exécutable et les librairies JIRA. Le répertoire de données est le

répertoire dans lequel sont stockées les données utiles au

fonctionnement de votre instance.

Sous Windows :

• Le chemin par défaut du répertoire d'installation est

• Et le chemin d'installation par défaut du répertoire de données est

Sous Linux :

• Le chemin par défaut du répertoire d'installation est

• Et le chemin d'installation par défaut du répertoire de données est

Notez qu'il est déconseillé de sauvegarder ces répertoires au « format

zip » car le format zip ne préserve pas les attributs des fichiers.

Préférez-lui le format « .tar.gz ».

Vous trouverez plus d'informations sur les répertoires d'installation et

de données JIRA ici : https://confluence.atlassian.com/jira/important-

directories-and-files-189891075.html

7. Sauvegardez vos spécificités

La plupart des éléments de personnalisation que vous avez mis en

place pour adapter JIRA aux besoins de votre environnement seront

écrasés pendant le processus de montée de version. Il faut donc veiller

à les sauvegarder pour permettre leur portage ultérieur.

Les éléments les plus souvent personnalisés par les clients sont :

• Le fichier server.xml, pour adapter la configuration du serveur Tomcat

• Le fichier setenv.sh (setenv.bat pour windows), pour adapter la configuration de la

JVM et des variables d'environnement

• Les fichiers velocity templates (".vm") pour personnaliser davantage l'IHM de JIRA

aux spécificités des utilisateurs

• Les certificats, pour sécuriser les connexions SSL

Il vous appartient donc de sauvegarder les modifications apportées à

ces fichiers afin de les reporter sur la version cible. Autrement, elles

seront définitivement perdues.

Rendez-vous ici pour en savoir plus sur comment utiliser JIRA via une

connexion SSL : https://confluence.atlassian.com/jira/connecting-to-

ssl-services-117455.html

8. Sauvegardez votre base de données

JIRA dispose d'un mécanisme de sauvegarde automatique des données

qui est désactivé par défaut pour des raisons de performance. Vous

faites bien de ne pas compter sur lui.

Atlassian recommande vivement d'utiliser les procédures natives de

sauvegarde et de restauration de vos outils lors des montées de version

JIRA.

Pour info, les bases de données supportées avec JIRA 7.0.x sont :

• Oracle 12C

• MySQL 5.1, 5.5 et 5.6

• PostgreSQL 9.3, 9.2, 9.1 et 9.0

• Microsoft SQL Server 2012 et 2008

D'une manière générale, vous trouverez ici les informations sur les

caractéristiques d'infrastructure requises pour JIRA 7 :

https://confluence.atlassian.com/adminjiraserver070/supported-

platforms-749382629.html

9. Effectuez votre montée de version selon la procédure choisie

C'est ici que vous déployez la procédure que vous avez sélectionnée à

l'étape 3. En théorie du moins.

En pratique, je demande toujours à mes clients de me fournir un

environnement ISO PROD pour tester la montée de version; de manière à

identifier, sans risque, les spécificités de leur infrastructure. L'exercice peut

prendre plus ou moins de temps d'un client à l'autre.

A titre illustratif :

• Je suis intervenu chez un client en Décembre 2015 pour une montée de version vers

JIRA 7

• Nous avons adopté une approche qui s'apparente à la procédure de mise à jour rapide

préconisée par Atlassian

• La montée de version a duré 6 jours en phase de test

• Elle n’a pris que 3h en production

Les 6 jours passés en phase de test nous ont permis d'identifier et d'écarter

les risques susceptibles d'être rencontrés en production.

10. Reportez vos spécificités

L'assistant de montée de version JIRA va automatiquement lancé

JIRA, si vous avez opté pour la procédure de mise à jour rapide.

Attendez qu'il l'ait lancé dans le navigateur pour arrêter JIRA

conformément à la procédure décrite en l'étape 4, puis reportez les

spécificités préalablement identifiées à l'étape 5.

Le report des spécificités consiste à recopier les fichiers spécifiques

dans les répertoires de la nouvelle version JIRA quand c'est possible.

Par exemple : recopier le certificat qui était initialement dans le

répertoire JRE/ de JIRA 6, dans le répertoire JRE/ de JIRA 7. Mais ce

n'est pas toujours aussi simple.

Dans d'autres cas en effet, il faut recopier manuellement la

configuration spécifique dans les fichiers de la nouvelle installation. Par

exemple : si vous avez personnalisé le fichier server.xml fourni par

défaut avec JIRA 6, vous ne pourrez pas vous contenter de le recopier

simplement dans les répertoires d'installation de JIRA 7. La version de

Tomcat utilisée d'une version à l'autre n'est en effet pas la même.

11. Redémarrez l’instance

La procédure de redémarrage de JIRA est à peu de chose près similaire

à la procédure d'arrêt présentée à l'étape 4.

Si vous utilisez un système de type Linux :

• Connectez vous en tant que root ("sudo -s", sous Debian)

• Rendez-vous dans le répertoire de l'exécutable JIRA (Généralement

"/opt/Atlassian/JIRA/bin")

• Exécuter la commande de démarrage de l'instance ("./start-jira.sh")

Si vous utilisez un système de la famille Windows :

• Rendez-vous dans le répertoire de l’exécutable JIRA (Généralement "C:\Program

Files\Atlassian\JIRA\bin")

• Exécuter la commande de démarrage de l'instance ("start-jira.bat")

La documentation fournie pour Mac OS X à l'étape 4 vaut aussi pour la

procédure de démarrage. Vous trouverez plus d'informations sur les

procédures d'arrêt et de démarrage de JIRA ici :

https://confluence.atlassian.com/display/JIRAKB/JIRA+application+Star

tup+and+Shutdown+Scripts

12. Déroulez les scénarios de test envisagés à l’étape 1

A ce stade, vous en avez terminé avec la partie technique. Il ne vous

reste plus qu'à faire quelques tests pour vous assurer que tout s'est bien

passé.

Vous pouvez réaliser les premiers tests. Il s'agit de vérifier que tout va

bien, à priori, avant d'associer le plus grand nombre. Confronter les

utilisateurs finaux à des bugs trop grossiers, facilement identifiables

relèverait en effet de la négligence et contribuerait à freiner l'adoption

de l'outil au sein de votre organisation.

Une fois cette première passe effectuée, je vous recommande

vivement d'associer les utilisateurs finaux. Ils connaissent mieux que

vous leur usage quotidien de l'outil et sont par conséquent plus équipés

pour discerner de subtils dysfonctionnements qui vous échapperaient.

C'est un peu l'équivalent des "Users Acceptance Test« , dans un

processus de recette classique.

13. Effectuez un roll-back

Si vous en arrivez là, c’est que la situation est vraiment désespérée…

L’assistant d’installation et de montée de version de JIRA ne fournit

pas de procédure de retour arrière automatique. Le roll-back passe par

la restauration des sauvegardes que vous avez effectuées aux étapes 5,

6, 7 et 8 de la procédure fournie par JIRA Club. C’est un peu le "système

D".

Si vous exécutez JIRA sur une machine virtuelle, l’idéal est de

disposer d'une machine virtuelle de test qui est une réplication exact de

la production pour tester la totalité de la procédure. Vous pourrez ainsi,

au passage, réaliser un snapshot de la VM de production qui peut être

restauré rapidement en cas d’échec.

Bien entendu, si vous avez opté pour la procédure fournie par

Atlassian pour des environnements hautement critique, sentez-vous

libre d'adopter la procédure de roll-back associée. Elle est documentée

ici : https://confluence.atlassian.com/adminjiraserver070/upgrading-

jira-applications-with-a-fallback-method-749382703.html

Conclusion

Ce kit s'appuie sur notre expérience des montées de version et sur

notre connaissance de la documentation mise à disposition par

Atlassian sur le sujet. Il est conçu pour vous aider à identifier le cadre

général dans lequel s'inscrit toutes les montées de version JIRA

auquelles nous avons été confrontées et devrait vous aider à tirer votre

épingle du jeu.

Il n'en demeure pas moins que chaque montée de version JIRA est

unique. D'abord parce que chaque version de JIRA est unique - en

particulier les versions majeures -, ensuite parce que votre

infrastructure possède probablement ses spécificités. Aussi, n'hésitez

pas à vous faire accompagner.

Nos équipes se tiennent à votre disposition pour répondre à vos

questions sur le sujet. Vous pouvez les joindre à tout moment via

l'adresse contact@jira-club.net.

A très bientôt sur www.jira-club.net,

L'Equipe JIRA Club