Déployer JIRA en entreprise : Les différents environnements

Visionnez nos Webinars à la demande | Agilité à l'échelle, IT Service Management, Cloud, Bonnes pratiques Jira, Témoignages clients... Cliquez-ici !

valiantys-logo
Back

Déployer JIRA en entreprise partie 1 : Les différents environnements

Cet article est le premier d’une série de trois articles consacrés à la gestion d’instances JIRA en entreprise. Ils exploitent les ressources mises à disposition par Atlassian (sur cette documentation notamment) ainsi que notre expérience d’experts Atlassian de longue date.

Mettre en place des serveurs de test

Lorsque l’on administre une (ou plusieurs) instance(s) JIRA, il est indispensable de disposer d’au moins un environnement de test (par instance !). Dans la plupart des entreprises, on distingue ces différents types de serveurs :

  • Production : serveur actuellement installé pour tous les utilisateurs.
  • Pré-production : serveur dont l’architecture est identique à celle du serveur de production, il permet de tester les procédures à l’identique avant de les appliquer en production. Il peut aussi servir à l’exécution de tests de performance (pour du capacity planning ou avant une montée de version)
  • Qualification : serveur permettant de tester différents changements comme la modification du code source de JIRA, l’installation d’un plug-in, le lancement d’un script, etc.
  • Développement : serveur sur lequel sont testés les développements spécifiques réalisés par les développeurs (s’il y en a). Les développeurs peuvent aussi disposer d’une instance locale.

Une fois ces différents environnements mis en place, vous devez établir une stratégie de déploiement des nouvelles fonctionnalités sur votre instance. Ces modifications peuvent être de différents types :

  • Modification d’un workflow existant : vous devez définir sur quels serveurs la modification devra être testée avant d’être mise en production. Il faut également définir qui sera en charge de cette modification : l’administrateur JIRA ou bien le demandeur de cette modification (à qui vous auriez donné des droits d’administrateur temporaires).
  • Ajout de plug-in : Qui a le droit d’installer un plug-in sur le serveur de Qualification ? Qui valide le déploiement (et éventuellement l’achat) du plug-in ? …
  • Développement d’un plug-in : Sur quel rythme sont mises en production les évolutions de ce plug-in ? Comment sont-elles communiquées aux utilisateurs ? Quel est le niveau de documentation attendu ? Où est stocké le code source ? Qui effectue les revues de code ? Quel outil de Gestion de Configuration Logicielle est utilisé ? …
  • Montée de version : Sur quel serveur est testée la montée de version ? Qui valide la procédure avant de l’exécuter en pré-production ? Quelles sont les étapes de communication aux utilisateurs finaux ? …
  • Etc.

Dans l’idéal, on doit pouvoir répondre à ces questions avant même de déployer JIRA. Mais rassurez-vous, il n’est jamais trop tard pour établir sa stratégie de déploiement.

Vous devez enfin décider (et communiquer) du rythme de mise à jour de vos différents serveurs. En effet, les données de ceux-ci doivent être le plus souvent possible à jour par rapport à la production, tout en les conservant suffisamment longtemps pour permettre des tests à plus long terme (impact de l’accumulation de données dans un plug-in par exemple).

Mettre à jour ses serveurs de test

Pour mettre à jour un serveur de test avec les dernières données du serveur de production,  il faut suivre ces différentes étapes :

  1. Récupérer le dossier <jira-home> de votre serveur de production et remplacer celui du serveur de test.
  2. Récupérer le dossier complet d’installation de JIRA et remplacer celui du serveur de test.
  3. Récupérer une sauvegarde de la base de données et l’importer dans une nouvelle base de données.
  4. Modifier le fichier <jira-home>/dbconfig.xml pour pointer sur cette nouvelle base de données.
  5. Modifier le fichier <jira-install>/WEB-INF/classes/jira-application.properties si le dossier <jira-home> est à un emplacement différent sur votre serveur de test.
  6. Démarrer votre serveur de test.
  7. Désactiver les serveurs de courriers électroniques (entrants et sortants).
  8. Modifier l’URL de base de votre instance.
  9. Modifier l’apparence de votre JIRA. On modifie souvent la couleur du bandeau supérieur afin de distinguer les différents types d’environnements. On peut également utiliser la bannière d’annonce de la même manière.
  10. Reconfigurer les Applications Links le cas échéant.

L’utilisation de serveurs de test permet de sécuriser votre plateforme de production, ce n’est donc pas un axe à négliger lors de votre déploiement de JIRA.

Le prochain article de cette série concernera le dimensionnement d’une plateforme JIRA, comment évaluer les volumétries présentes sur l’outil dans un an avant même de l’avoir installé ?

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.