Cet article a été écrit par Kamil Beer, un ingénieur Atlassian à iDalko.

La migration des outils Atlassian est toujours un sujet d’actualité. Il est certainement possible de changer de type de déploiement, mais il faut bien réfléchir avant l’exécution. Ainsi, dans la première partie de la série, « Bonnes pratiques : maintenir la pile Atlassian », j’analyse en détail la façon de migrer Jira.

Je vous expliquerai également toutes les étapes nécessaires que vous devez suivre avant, pendant et après la migration de votre Jira. Donc, si vous cherchez le guide ultime pour une migration sécurisée, continuez à lire.

Avant d’en arriver au contenu, vous pouvez télécharger cette fiche de travail :

Voici un aperçu de ce que nous allons couvrir dans ce guide détaillé :

Chapitre 1– Avant la migration de Jira : quels modèles de déploiement dois-je choisir pour ma pile Atlassian ?
1.1. Sur Cloud or sur Server?
1.2. Limitations du déploiement 
Chapitre 2– Se préparer à la migration de Jira: Analyse et nettoyage
2.1. Analyse de la nouvelle plateforme 
2.2. Nettoyage de l’instance 
Chapitre 3– Comment tout planifier efficacement avant de migrer Jira
3.1. Server vers Cloud
3.2. Importation de site ou Assistant de migration ? 
Chapter 4– Transit, tests et exécution : C’est le moment de migrer votre Jira 
4.1. Transit de la Migration Server 
4.2. Test d’acceptation par l’utilisateur
4.3. Migration de la production
4.4. Support après migration

Chapitre 1 – Avant la migration de Jira : quels modèles de déploiement dois-je choisir pour ma pile Atlassian ?

Avant d’en arriver à la partie où je discuterai en détail de la manière de migrer Jira, je commencerai par passer en revue les modèles de déploiement dont nous disposons. Les chemins à parcourir dans le monde Atlassian sont nombreux, avec le risque de se tromper lors du choix du modèle de déploiement de votre pile Atlassian. Comment déployer Jira ? Quelles règles dois-je mettre en place ? Et la sécurité ? Comment maintenir l’application ? En tant qu’administrateur, vous vous êtes probablement déjà posé ces questions.

Heureusement, ces chemins ont déjà été parcourus par de nombreux experts, notamment ceux de iDalko. Et c’est ce que notre nouvelle série d’articles va couvrir, les bonnes pratiques de la pile Atlassian, basées sur notre expérience.

Très bien, vous avez donc décidé d’utiliser Jira – ou Confluence ou Bitbucket – pour vous aider. Excellent ! Vous avez cherché comment l’installer et vous avez rencontré la première intersection. Où l’application doit-elle s’exécuter ?

Sur Cloud ou sur Server ?

Et ils ne mentionnent même pas la troisième option : Data Center. Alors, quel est le bon choix ?

Dans ce chapitre, je vais décrire les choix de déploiement, leurs avantages et leurs inconvénients. Il est utile aussi bien aux administrateurs novices qu’aux vétérans, surtout avant de migrer votre Jira.

Cloud

En bref : Cloud signifie qu’Atlassian héberge l’application.

Le déploiement de Cloud existe depuis 2008. Atlassian a commencé à offrir une plateforme de développement avec Jira, Confluence, SVN, Crowd, Bamboo, Fisheye et Crucible appelé Jira Studio. En 2011, un produit dénommé OnDemand a permis l’utilisation de demandes séparées, contrairement à Jira Studio groupé. En 2013, Jira Studio a été abandonné et OnDemand a été dénommé Cloud en 2014.

Donc, avec Cloud, vous n’avez pas besoin de fournir l’infrastructure applicative ou d’effectuer des tâches d’administration de serveur compliquées. Mais il y a d’autres éléments à prendre en compte, détaillés ci-dessous.

Pour (ne pas) rester simple, il existe quatre types de déploiement Cloud :

• Cloud Free, introduit en mars 2020, vous permet d’utiliser gratuitement Jira Software, Core, Service Desk, Confluence, Trello, Bitbucket et Opsgenie. C’est une bonne introduction, mais les limitations ne la rendent pas très viable en production (par exemple, Jira manque d’autorisations, Bitbucket est limité à 5 utilisateurs).
• Cloud Standard est la solution Cloud la plus courante. Cet article présente en détail ses avantages et ses inconvénients.
• Cloud Premium est un Cloud Standard plus puissant. Il dispose d’un SLA de disponibilité de 99,9 %, d’un stockage de fichiers illimité et d’une assistance 24 heures sur 24, 7 jours sur 7. Les nouvelles fonctionnalités comprennent l’autorisation d’IP et l’archivage de projets. Pour les petites équipes, les utilisateurs coûtent deux fois plus cher (par exemple, un utilisateur dans JSW coûte 7 $ pour Cloud Standard et 14 $ pour Cloud Premium). Mais plus vous avez d’utilisateurs, plus l’augmentation des prix sera faible.
• Cloud Enterprise (en Early Access) va encore plus loin. Avec des utilisateurs illimités, un SLA de disponibilité de 99,95 %, la possibilité de choisir Data Residency et « l’intégration garantie avec de nombreux outils SaaS d’entreprise essentiels », c’est un rêve qui deviendrait réalité pour de nombreuses équipes, mais aussi à un coût qui ne le rendra pas accessible à la plupart d’entre elles. Vous pouvez l’essayer ici.

Maintenant que nous avons couvert les types de Cloud, voyons ce que Cloud Standard peut offrir.

Les avantages

Vous payez par utilisateur, et non en vrac. Dans Cloud, vous payez pour chaque utilisateur actif dans l’application. Mais dans Server ou Data Center, vous achetez des licences en vrac. Dans Server, les niveaux de prix sont 10/25/50/100/250/500/2000/10000+.

Vous avez probablement remarqué les grands écarts – et oui, cela signifie qu’une fois que vous avez atteint 501 utilisateurs sur Server, vous devez acheter la licence bien plus coûteuse pour 2000 utilisateurs, y compris toutes les applications que vous utilisez. Dans Cloud, vous ne paieriez que pour cet utilisateur supplémentaire. Toutefois, cette option ne s’applique qu’à l’abonnement mensuel Cloud. Les paiements annuels de Cloud ont toujours leurs propres niveaux d’utilisation.

Exemple de prix – Jira Software

Pas de coûts de matériel. Vous n’avez pas besoin d’acheter ou de louer des serveurs, ni de vous occuper de leur maintenance, de leur mise à l’échelle, de leur dépréciation, de leur refroidissement ou de l’électricité. Vous n’avez pas besoin d’embaucher des employés pour le faire à votre place. Cette tâche est prise en charge par Atlassian qui héberge toutes ses solutions de cloud via AWS. Ces serveurs sont situés partout dans le monde pour un meilleur accès et de meilleures performances.

Et même si vous avez toujours besoin d’un administrateur, toutes les tâches nécessaires sont effectuées via l’interface utilisateur.

Mises à niveau faciles. Vous n’avez pas besoin de temps d’arrêt, de longs déploiements sur des instances de développement et de test, ni de participer au processus ardu de mise à niveau d’une instance. Les mises à niveau sont effectuées en arrière-plan par Atlassian. Vous arrivez simplement dans une instance mise à niveau avec de nouvelles fonctionnalités.

Les désavantages

Personnalisation et support réduits des logiciels populaires. La personnalisation des applications Cloud est très limitée : vous ne pouvez utiliser que certaines applications de Server, ou certaines fonctionnalités clés auxquelles vous étiez habitué peuvent manquer (par ex. Scriptrunner, JEMH).

Certains logiciels d’entreprise populaires, comme Active Directory, ne sont pas non plus pris en charge. Vous aurez du mal avec les intégrations. Différents paramètres du système sont manquants (pas de modèles prioritaires), d’autres ne peuvent pas être personnalisés (par ex. votre propre URL).

Pas de domaine personnalisé. Chaque fois que vous enregistrez une application Cloud, elle comporte un domaine de deuxième niveau «atlassian », comme : https://yourname.atlassian.com/. Il n’est actuellement pas possible de changer cela – les difficultés pour y parvenir ont été décrites par le développeur principal de cette fonctionnalité ici.

Nombre d’utilisateurs réduit. Sur Cloud, le nombre maximum d’utilisateurs est de 5000. Cela pourrait poser un problème dans les grandes organisations, car il faudrait alors fédérer plusieurs instances.

Modèle d’abonnement. Contrairement à Server, qui dispose d’une licence perpétuelle (le prix initial correspond à l’application et à une année de maintenance que vous n’avez pas à payer à nouveau), Cloud nécessite des paiements mensuels ou annuels pour continuer à fonctionner. Il s’agit d’un modèle SaaS standard. Toutefois, cela signifie qu’une fois que vous n’avez plus besoin de mises à niveau et que vous souhaitez toujours utiliser l’application, vous devez payer l’instance ou perdre vos données. Vous avez également la possibilité de migrer Jira vers une instance Server.

Server

En bref : Server signifie que vous hébergez l’application.

Remarque : Atlassian a annoncé la fin du support pour Server à partir du 2 février 2021. Atlassian ne fournira donc plus de licences pour les utilisateurs de Server à partir de cette date.

Jira 1.0 a été fait en 2002 pour travailler sur place. D’autres applications, telles que Confluence, Bitbucket, Crowd, Fisheye et Crucible, sont également prêtes pour un déploiement local.

Alors, de quoi avez-vous besoin lorsque vous déployez localement ? Certainement, le serveur de votre propre fournisseur d’hébergement pour exécuter l’application (Linux, Windows Server, AWS ou Azure sont toutes des options), une base de données, un système de fichiers et un administrateur qui peut tout mettre ensemble. Au début, l’aide de certains autres techniciens informatiques peut également être nécessaire. Et si tout cela peut sembler être un gros investissement, il en vaut la peine.

Les avantages

Facilité d’utilisation. Bien sûr, vous aurez peut-être besoin de mettre à niveau de temps en temps, mais personne ne changera radicalement votre application ou ses fonctionnalités sans vous. Si vous voulez la garder telle quelle, après que vos utilisateurs se soient familiarisés avec l’outil, rien ne s’y oppose.

Nouvelle interface utilisateur (Cloud) ancienne interface utilisateur (Server) ?

Dans Cloud, des fonctionnalités apparaissent et disparaissent, tout comme l’interface utilisateur dont de nombreux utilisateurs se sont plaints dans les liens ci-dessus. Dans Server, une fois que vous aurez créé votre instance, elle restera telle quelle. Peu de gens aiment les changements, mais s’ils sont nécessaires, vous pouvez les approuver d’abord, ou faire un rollback plus tard. Et ce qui aide, c’est…

Des licences perpétuelles de modèle et de développeur. Une fois que vous achetez une licence de serveur Atlassian, vous obtenez l’application et une année de maintenance. La maintenance payante signifie l’accès à de nouvelles mises à niveau et à un canal d’assistance Atlassian très utile.

Après l’expiration de la maintenance, vous pouvez la prolonger pour 50 % du coût du niveau d’utilisateur de la licence actuelle pendant une autre année. Mais même si vous ne le faites pas, vous pouvez continuer à utiliser l’application. Cependant, avant que la maintenance n’expire, vous devez passer à la dernière version stable.

Vous obtenez également une licence de développement, qui est une copie de votre licence de production que vous pouvez utiliser pour les serveurs de non-production, par exemple, une instance de transit pour les tests de mise à niveau, les essais d’applications ou les changements importants, une instance de test pour que vos utilisateurs puissent se familiariser avec l’application, ou une instance d’archive pour les anciens projets/espaces/référentiels.

Cependant, de temps en temps, diverses vulnérabilités de sécurité apparaissent, et l’une des solutions consiste à mettre à niveau l’application. Si vous n’avez pas de maintenance active, cela peut devenir un gros problème, mais même dans ce cas, vous pouvez…

Garder votre pile Atlassian dans un réseau privé. Contrairement à l’instance Cloud, qui est visible par tout le monde, vous pouvez mettre l’instance Server dans votre VPN. C’est à la fois une bonne étape, du point de vue de la sécurité, et un moyen de repousser les tentatives de piratage visibles sur Internet. Récemment, Atlassian a publié une version bêta d’une fonctionnalité qui permet la mise en liste blanche d’IP sur Cloud Premium, mais il manque encore une véritable intégration des applications à l’intérieur d’un réseau privé.

Les aspects de sécurité se compliquent encore plus sur Cloud avec les applications tierces, car les données qu’elles traitent ne sont pas hébergées par Atlassian, mais par les fournisseurs. Cela pourrait entraîner la non-conformité du RGPD. Sur Server, tout reste sur votre machine.

Garder Jira ou Confluence dans un réseau privé est toujours l’une des capacités les plus demandées pour les déploiements en entreprise.

Disponibilité. Il n’y a pas de temps de disponibilité garanti pour une application Cloud Atlassian. Lorsque votre instance Cloud est hors service, vous soumettez un ticket au support Atlassian… et vous attendez. Si vous utilisez Server, le temps de fonctionnement dépend de vous. Si vous y préparez votre infrastructure, des résultats impressionnants et de faibles temps d’arrêt peuvent être obtenus, par exemple via un pipeline Docker en grappe, même dans les environnements d’entreprise.

Bien qu’Atlassian garantisse un temps de disponibilité de 99,9 % pour les plans Cloud Premium, c’est environ 45 minutes de temps d’arrêt par mois, en théorie et dans des circonstances parfaites.

Accès. Vous pouvez accéder au système de fichiers et à la base de données et effectuer diverses modifications et intégrations personnalisées. Votre système de fichiers peut être mis à l’échelle en fonction de la croissance de l’instance, ce qui n’est pas le cas avec Cloud, qui dispose d’un espace de fichier maximum de 250 Go.

Les désavantages

Investissement d’Atlassian. Quelques sommets Atlassian étaient presque uniquement axés sur Cloud et Data Center. Il n’y a pas beaucoup de nouvelles fonctionnalités impressionnantes faites pour Server (par ex. Automation for Jira ou Jira Suite Utilities restent encore une application payante, contrairement à ce qui se passe sur Cloud).

Tarification des utilisateurs en vrac et autres questions de tarification. Nous avons déjà mentionné le fait de payer le matériel, les logiciels, le personnel, etc. Un autre obstacle pourrait concerner les licences, avec de grandes différences entre les nombres d’utilisateurs (si vous avez 501 utilisateurs, vous devez acheter la licence de 2000 utilisateurs) – y compris les applications. Certains de ces problèmes peuvent être résolus en omettant la maintenance de certaines applications ou de l’instance principale, à vos propres risques.

Il est à noter aussi deux importantes augmentations de prix d’Atlassian en octobre 2019. Les utilisateurs qui ont acheté 3 ou 5 ans de maintenance avant ont sans aucun doute fait le bon choix. D’autres augmentations sont attendues à l’avenir, car les prix ont augmenté presque chaque année au cours de la dernière décennie.

Atlassian ne peut pas aider à distance. Sur une instance Cloud, si elle tombe en panne, les techniciens Atlassian se connecteront à votre instance en tant qu’administrateur système et vérifieront ce qui ne va pas. Sur Server, ils ne peuvent aider que par l’intermédiaire du service d’assistance, qui est toujours très utile. Vous devez également fournir divers journaux et fichiers, idéalement sous la forme d’un support zip.

Data Center

En bref : Data Center signifie que vous hébergez l’application en utilisant la puissance de plusieurs serveurs.

Le déploiement de Data Center a d’abord été rendu disponible pour Jira 6.4 en 2014, puis pour la version 7.0 en 2015, lorsque Jira a été divisé en Jira Core, Jira Software et Jira Service Desk.

D’autres outils ont rapidement suivi, avec Confluence Data Center étant déjà disponible en septembre 2014 et Bitbucket Data Center (appelé Stash à cette date) en mars 2015. En août 2017, Crowd est entré dans la famille Data Center.

Mais qu’apporte exactement le déploiement de Data Center ?

Tout d’abord, il exécute l’application sur plusieurs serveurs. Cela signifie qu’il offre de meilleures performances et peut supporter une charge plus lourde qu’une instance Server.

Deuxièmement, il fournit une solution de secours. Le serveur A est peut-être en panne, mais votre application fonctionnera toujours à partir des serveurs B et C. Pratique et utile lorsque vous avez besoin d’un temps de fonctionnement élevé, par exemple pour de la documentation ou un service d’assistance.

Les avantages

Une réelle haute disponibilité. Sur Server et Cloud, il y a un point de défaillance unique. Sur Data Center, vous pouvez vous connecter à autant de serveurs que vous le souhaitez et vous assurer qu’ils vous maintiendront en ligne. De plus, le temps d’attente pour obtenir la sauvegarde de votre site Cloud ou Server n’est plus un problème.

Performance évolutive. Lorsque votre instance Jira Server passe à environ 200 000 incidents, vous devez faire des cascades très avancées pour qu’il fonctionne bien. En répartissant la charge entre plusieurs serveurs avec DC, vous pouvez faire évoluer l’instance encore plus loin. C’est aussi un moyen d’alléger au maximum la pression sur une application en pleine expansion que vous avez déjà mise à l’échelle. Là encore, vous pouvez toujours ajouter des serveurs supplémentaires hébergés soit localement, soit sur AWS/Azure pour améliorer les performances.

SSO 2.0 Un avantage intéressant est l’ajout de la connexion SAML à Azure AD, à ADFS et à plusieurs autres fournisseurs d’identité. Cela permet une authentification unique dans les outils Atlassian. Notez que pour SSO, vous pouvez choisir soit Crowd soit votre fournisseur d’identité local, et non les deux.

Exemple de schéma de déploiement de Data Center

Les désavantages

Le coût. Avec l’exception de Bitbucket, le niveau de départ de Data Center est de 500 utilisateurs (Jira/Confluence) ou 50 agents (Jira Service Desk) à 12 000 dollars par an. Et ce n’est que l’application principale : vous devez y ajouter le prix de toute application tierce. Il est clair que ce déploiement est réalisable principalement pour l’entreprise. Bien que Bitbucket DC disponible à partir de 11 utilisateurs semble certainement intéressant, il faut peser la valeur qu’il apporterait réellement par rapport à une instance Server ordinaire.

Modèle de licence. Même si vous hébergez Data Center, le modèle de licence est différent de celui de Server. Vous devez payer le même coût chaque année.

Limitations des clusters. Si Data Center peut être déployé sur plusieurs serveurs, vous devez également préparer le reste de l’infrastructure à la haute disponibilité. Cela signifie le système de fichiers (par ex. en utilisant GlusterFS) et la base de données (de nombreux fournisseurs de bases de données proposent aujourd’hui une solution haute disponibilité). Ils doivent également tous être compatibles et pris en charge, ce qui pourrait ne pas toujours être facile.

Limitations du déploiement

Maintenant que vous connaissez les principales propriétés des trois déploiements, il y a un autre point à considérer : certaines applications peuvent être déployées uniquement dans Cloud, d’autres uniquement sur la version Server, et quelques-unes seulement peuvent être déployées dans Data Center. Heureusement, il y a un grand chevauchement – voir ci-dessous.

Résumé

Cloud, Server, Data Center sont les options de déploiement qu’un administrateur Atlassian devrait connaître. Si Cloud peut s’avérer utile dans les cas où vous n’avez pas de serveur disponible pour héberger vos données, Server peut être plus utile lorsque vous en avez un et lorsque vous exécutez de plus en plus de cas d’utilisation et de personnalisations. Data Center devient pertinent une fois que vous avez atteint l’échelle de l’entreprise.

Ce chapitre les a tous présentés en détail. Mais peut-être avez-vous déjà choisi votre hébergement, mais il ne fonctionne pas aussi bien que prévu initialement. Vous pourriez même envisager de migrer vers un autre.

Dans le prochain chapitre, j’explorerai donc tout ce qui concerne la préparation avant la migration de Jira.

Chapitre 2 – Se préparer à la migration de Jira : analyse et nettoyage

Au chapitre précédent, nous avons couvert les modèles de déploiement des outils Atlassian et leurs avantages et leurs inconvénients. Mais si vous avez déjà une instance Jira en place et opérationnelle, ce chapitre vous aidera à vous préparer pleinement à la migration de Jira.

Alors peut-être avez-vous découvert qu’un élément essentiel dont vous avez besoin dans Jira n’est pas sur Cloud. Ou, vous avez découvert que vous avez besoin de mettre à jour votre Confluence sans programmer des temps d’arrêt de Server tout le temps. Ou, vous avez découvert que vos nombreuses équipes de développement ont besoin d’un Bitbucket toujours en ligne – peut-être dans un Data Center. Ce chapitre est destiné à ceux qui sont aux prises avec cette situation pour les aider à réussir la migration de leur instance Jira.

Déplacer votre application de Cloud vers Server, et vice versa, et même vers Data Center est certainement possible. Mais chaque plateforme a des exigences, des comportements et même une apparence différents, il est donc nécessaire de mettre au point une stratégie. Que faut-il faire pour exécuter une migration Jira de la meilleure façon possible ?

Je vais couvrir ici les deux étapes de la préparation : l’analyse et le nettoyage.

Analyse de la nouvelle plateforme avant de migrer Jira

La première étape de ce voyage consiste à examiner attentivement et honnêtement si la nouvelle plateforme répond à vos besoins, ce qui va changer, et si la migration de Jira est même possible. Il y a plusieurs angles à cela :

Le prix

Il est nécessaire de prendre en considération le changement de prix potentiel. Pour illustrer notre propos, nous avons comparé les coûts de Jira Software pour 100, 1000 et 2000 utilisateurs sur Cloud, Server et DC. Nous avons inclus cinq applications populaires : Tempo Timesheets, eazyBI, JMWE, ScriptRunner et Xray, et créé un devis pour cinq ans (juin 2020).

Pour Cloud, nous avons utilisé la tarification annuelle standard et avons économisé deux mois de paiement par rapport au modèle mensuel. Pour Server, les prix contiennent la maintenance payée chaque année. Vous pouvez toutefois ne pas payer la maintenance et continuer à utiliser l’application.

Aucune remise n’a été appliquée, il s’agit donc des prix officiels d’Atlassian en USD, cumulés au fil des ans.

Vous pouvez également créer votre propre devis ici :

• Cloud
• Server

Jira Software – 100 utilisateurs

Au cours des deux premières années, le prix de Cloud était similaire à celui de Server. À partir de la troisième année, la différence de prix penche davantage en faveur de Server. Les frais d’hébergement et de personnel ne sont pas inclus dans le prix de Server, pas plus que la décision de ne pas renouveler la maintenance. Cela peut être utile si vous êtes isolé derrière un pare-feu et moins vulnérable aux exploits de sécurité.

Jira Software – 1000 utilisateurs

Le niveau 1000 utilisateurs est disponible sur Cloud Standard. Sur Server, vous pouvez acheter une licence pour 500 ou 2000 utilisateurs. Mais même ici, nous constatons que plus le temps passe, plus le prix de Server augmente. Le prix de Data Center pour 1000 utilisateurs reste généralement meilleur que celui de son homologue pour 2000 utilisateurs.

Jira Software – 2000 utilisateurs

Dans un grand nombre de cas, la différence de prix entre Cloud/Serveur devient beaucoup plus visible. Ici, Data Center est une option viable dont le prix se situe entre Cloud et Server.

Conformité et sécurité

Le RGPD est également un élément à prendre en compte lors du changement des déploiements. Si vous êtes situé en Europe et souhaitez migrer vers Jira Cloud, réfléchissez bien. De nombreuses entreprises signent des contrats ou des accords de non-divulgation avec leurs clients ou fournisseurs, stipulant que les informations confidentielles restent sur les serveurs locaux. Cette situation change radicalement dans Cloud, car les données peuvent être stockées ailleurs. Ainsi, tous ces accords devront être modifiés au fur et à mesure que vous passerez de Server/ Data Center. Dans les entreprises, ces révisions peuvent prendre des années.

Si vous travaillez derrière un pare-feu, vous devrez mettre sur liste blanche 7 domaines, un grand nombre de plages IP, les services Amazon/ Cloudflare requis et divers sites d’applications tiers pour Cloud. Atlassian indique que vous devez tout autoriser avec un nom de service « Amazon » ou « Cloudfront », plusieurs IP pour recevoir des notifications, et encore un autre ensemble d’IP pour Trello et Bitbucket. Vous pouvez en savoir plus ici. Vous devrez le faire sur chaque pare-feu. Même les produits Server auront besoin de mise en liste blanche, principalement pour Atlassian Marketplace.

Un autre point est votre base d’utilisateurs. Disons que vous utilisez Crowd, connecté à votre Active Directory, et fournissant SSO sur Server. Ou vous utilisez Atlassian Access avec Azure AD ou GSuite et passez sur Cloud. Crowd n’est pas disponible sur Cloud – et vous devrez acheter une application supplémentaire pour intégrer GSuite et ADFS sur Server. Quel sera l’authentificateur (ou le fournisseur de SSO) après la migration ?

Par ailleurs, Cloud Standard ne prend en charge que 5000 utilisateurs, dans le cas où vous avez un déploiement de Server/DC d’entreprise et que vous souhaitez migrer Jira vers Cloud, alors attention !

Si vous migrez Jira vers Server à la place, sachez que vous devrez renforcer vous-même votre serveur d’application. Cela signifie construire un proxy, fournir un certificat SSL, changer les ports pour SSH, déployer une application comme fail2ban.

Expérience utilisateur

La plupart d’entre nous résistent au changement, et changer une application que vous utilisez quotidiennement en est un gros. Les utilisateurs seront surpris même par des couleurs différentes, sans parler des divers boutons qui ne sont plus là où ils étaient. Et les utilisateurs ont finalement appris où est quoi et comment ça fonctionne.

Ou bien ils peuvent détester la nouvelle conception. Il y a eu une opposition importante après le changement de l’interface utilisateur Cloud 2017, à tel point q’Atlassian est revenu à l’ancienne interface utilisateur à la fin de l’année 2019. La résistance des utilisateurs est une chose à laquelle il faut se préparer, quelle que soit la plateforme vers laquelle on migre.

Vous pouvez atténuer ce problème en fournissant des ressources d’apprentissage aux utilisateurs et en les avertissant à l’avance. Atlassian dispose d’une grande bibliothèque de formation gratuite et nous à iDalko avons préparé un manuel utilisateur avec lequel vous ne vous perdrez pas !

Caractéristiques

Si vous utilisez des intégrations sur Server, elles pourraient ne pas fonctionner du tout sur Cloud. L’accès direct à la base de données ne sera pas disponible, vous devrez donc reconstruire ce que vous pouvez dans l’API REST. Les anciens systèmes seront fortement touchés et l’intégration de logiciel COBOL ou FORTRAN semble tout simplement difficile à imaginer. Pareil pour les hacks ou applications personnalisés. Les transférer sur Cloud pourrait être impossible, Atlassian vérifie toutes les applications Cloud et respecte des normes strictes. Et, les applications sur Cloud et Server sont aussi écrites différemment.

Les applications Cloud sont écrites en « Atlassian Connect », un cadre différent de celui de Java one on Server. Sur Server, une application est installée directement dans le logiciel, mais une application Cloud est une application web distincte connectée, par exemple, à Jira par l’API REST. En savoir plus sur ce type de déploiement ici.

Les applications comme Power Admin, JMCF ou Rich Filters n’ont tout simplement pas de variante Cloud. Cependant, on peut dire sans risque de se tromper que plus l’application est populaire, plus il y a de chances de la voir sur tous les déploiements. Certaines applications ont des fonctionnalités limitées, comme l’ensemble de fonctionnalités très différent de Scriptrunner. D’autres pourraient ne pas migrer les données correctement, facilement ou pas du tout.

Même s’il n’est pas facile de transférer toutes les applications/intégrations de Server vers Cloud ou vice versa, il est utile de tester d’abord si toutes les fonctionnalités ont migré en utilisant une instance de démonstration. Et ensuite, pour vérifier toutes les différences d’application dans la documentation du vendeur.

Si vous migrez vers Cloud, une instance de démonstration peut être plus difficile, car votre meilleure option est une version d’essai. Il y a des rumeurs d’un environnement Sandbox, mais seulement sur le déploiement Cloud Premium.

Autres points à considérer

• Combien de temps d’arrêt pouvez-vous vous permettre ? Cloud Standard n’a pas de temps de fonctionnement garanti.
• Quels changements de surveillance (via Nagios, Grafana…) devrez-vous effectuer ?
• Lors de la migration de Cloud vers Server, votre administrateur d’application aura des tâches supplémentaires – il devra également administrer le serveur.
• Comment allez-vous maintenir vos sauvegardes lorsque vous passerez de Jira Cloud à Server ?

Nettoyage de l’instance avant de migrer votre Jira

L’analyse s’est-elle bien déroulée ? Bien ! L’étape suivante consiste à mettre de l’ordre dans votre instance afin de ne pas reporter d’anciennes données ou une configuration inutilisée. Même si vous n’avez pas migré Jira au final, c’est une procédure utile à effectuer une ou deux fois par an.

Alors, comment le faire ? Il existe de nombreux moyens, mais mentionnons les étapes les plus courantes. Nous nous concentrerons sur la manière d’effectuer un nettoyage dans l’un de nos prochains articles.

Archivage des projets, des espaces et des référentiels

Si vous utilisez Jira, Confluence ou Bitbucket depuis un certain temps déjà, il est probable que les utilisateurs n’utilisent plus nombre d’entre eux. Il peut s’agir de projets terminés, d’anciens outils de documentation ou de formation, de doublons, etc. qui occupent inutilement de l’espace dans les bases de données et les fichiers.

Une bonne façon de déterminer si un projet Jira est utilisé consiste à trier ses incidents par leur date de mise à jour. Avec une application tierce comme Rich Filters ou Power Admin, il est encore plus facile de trouver la dernière date de mise à jour.

Confluence affiche l’activité des espaces sur la page d’accueil par défaut de chaque espace. Si vous utilisez Better Content Archiving, vous verrez quelles pages sont modifiées et lues dans chaque espace. Dans Bitbucket, chaque référentiel a une date de dernière mise à jour.

Archivez Jira/Confluence/Bitbucket en prenant simplement une copie de sauvegarde, en confirmant son intégrité et en supprimant l’ancien contenu de la production.

Suppression des objets anciens et en double

Après la suppression des projets, de nombreux workflows ou champs personnalisés ne seront plus utilisés. Vous devez les supprimer, car les administrateurs auront plus tard du mal à trouver ceux dont ils ont besoin. Et le fait d’avoir trop de champs ralentit Jira lors de la recherche et de la consultation des incidents. Pour en savoir plus, regardez cette vidéo.

Vous trouverez les objets inutilisés dans chacune de leurs sections respectives, pour les workflows, les écrans, les différents modèles… ou vous pouvez utiliser Power Admin ou Optimizer for Jira (payant) pour faire cette vérification d’usage à votre place.

Pour vérifier si un champ personnalisé est utilisé, une requête facile à utiliser est <name of field> IS NOT Empty pour voir combien d’incidents utilisent effectivement ce champ personnalisé.

Suppression des utilisateurs inutilisés

Cette action vous permettra d’économiser de l’argent et d’améliorer la sécurité. Chaque fois qu’un utilisateur quitte ou cesse d’utiliser l’application, la meilleure pratique consiste à le désactiver. Cependant, vous pouvez parfois oublier et leurs comptes resteront actifs. En tant que point d’accès, c’est un risque de sécurité et cela rend l’utilisation de la licence plus élevée. Les comptes inutilisés doivent être supprimés avant de migrer votre instance Jira.

Il n’est pas facile de vérifier quels utilisateurs sont actifs, à moins de fouiller dans la base de données (et seulement sur Server/ Data Center) ou de vérifier manuellement chaque utilisateur. User Management for Jira est une application utile qui affiche les utilisateurs qui ne se sont pas connectés depuis un certain temps ou pas du tout, disponible pour Jira, Confluence et Bitbucket.

Vérification des erreurs

Lors de la migration vers Cloud, ne migrez pas les mauvaises configurations. Ainsi, à moins de vouloir tout reconstruire à partir de zéro, la vérification des journaux d’application et de l’intégrité de l’instance permet d’identifier les erreurs dans la configuration actuelle et leur cause.

Vous pouvez soit lire vos journaux manuellement, soit utiliser Jira/Confluence Log Analyzer qui analyse votre journal à la recherche d’erreurs et vous dirige vers les articles pertinents d’Atlassian KB. Vous pouvez aussi utiliser l’application gratuite Integrity Check pour une nouvelle recherche de cartes, tableaux de bord et projets Jira mal configurés.

Audit de l’utilisation des applications

Des milliers d’applications sont disponibles et peuvent être utilisées gratuitement pendant 30 jours. Il est donc tentant de toutes les essayer. Elles resteront toutefois installées après la période d’essai. Ou peut-être que vous utilisez une application qui était populaire autrefois, mais que les utilisateurs ont cessé d’utiliser. Ne faites pas migrer des applications inutilisées qui prennent de la place et augmentent les coûts. Il en va de même pour les applications dotées de fonctions redondantes, comme les modificateurs de workflow Jira ou les améliorateurs de tableau Confluence.

Vous pouvez trouver l’utilisation de certaines applications avec Power Admin ou Admin Toolbox, principalement des applications de workflow comme JMWE, JSU ou ScriptRunner.

Les applications qui apportent de nouvelles fonctionnalités et créent de nouveaux objets, comme les portfolios dans Portfolio for Jira (maintenant Advanced Roadmaps), les programmes BigPicture ou Object Schemes in Insight peuvent être audités en vérifiant la dernière date de mise à jour de chacun des objets qu’ils créent, en plus de demander simplement à leurs utilisateurs.

Enfin, il existe des applications sans trace d’utilisation évidente, comme divers gadgets ou macros. Recherchez-les dans la base de données, en utilisant le nom de l’application. Par exemple, tapez com.qotilabs.jira.rich-filters-plugin pour rechercher tous les gadgets Rich Filters.

Résumé

Une fois que vous avez décidé quel modèle de déploiement vous convient le mieux, il est temps de migrer Jira vers la destination souhaitée. Mais si vous vous y préparez, si vous analysez la plateforme et les changements possibles, et si vous procédez à un bon nettoyage, la migration peut être bien plus facile et moins longue.

Avez-vous fini et êtes-vous prêt à migrer Jira ? Ensuite, passons au chapitre suivant sur la planification de votre migration Jira.

Chapitre 3 – Comment tout planifier efficacement avant de migrer Jira

Au chapitre précédent, j’ai analysé s’il fallait ou non migrer Jira, et j’ai également fourni quelques conseils pratiques sur la façon de nettoyer l’application avant d’exécuter la migration. Ici, je me concentrerai plus particulièrement sur la planification de la migration et sur les étapes à suivre pour exécuter cette grande opération en petits morceaux faciles à gérer.

Très bien ! Votre instance est parfaitement visible et vous êtes certain de vouloir la déplacer ailleurs. Nous vous aiderons à suivre les étapes nécessaires à la migration et à éviter les pièces sur le chemin.

Nous couvrirons les migrations de Server vers Cloud, avec Jira comme application que nous déplacerons.

Server vers Cloud

La migration vers Jira Cloud est devenue très populaire ces derniers temps, car Atlassian souhaite faire passer les clients Server vers Cloud.

Une option consiste migrer Jira en utilisant un Assistant de migration : les applications gratuites Jira Cloud Migration Assistant et Confluence Cloud Migration Assistant.

Les caractéristiques de JCMA ressemblent à Configuration Manager, une application populaire de migration de projets Jira : vous choisissez non seulement les projets à migrer, mais aussi des utilisateurs et des groupes spécifiques. JCMA est disponible pour Jira 7.6 et versions supérieures et CCMA pour version 5.10. et supérieures.

Une autre façon de migrer Jira est de faire une importation de site normale.

Comme avec Server, vous devez connaître toutes les limitations de Cloud. Par exemple, la disponibilité de l’application, la perte de personnalisation, la limite d’utilisateurs, la taille maximale des pièces jointes, et divers autres écueils. Pour en savoir plus sur ce sujet, consultez le premier article de cette série ici.

Encore une fois, vous aurez d’abord besoin d’une licence valide. Ce qui aide, c’est l’« essai de migration étendu » d’Atlassian qui vous permet d’utiliser le site Cloud jusqu’à l’expiration de votre licence Server/ Data Center. Cela signifie que vous n’avez pas à vous soucier de l’échéance commune ou de payer une licence supplémentaire lorsque vous êtes encore sur Server. Vous pouvez l’essayer dans le cadre de Cloud Classic ou Cloud Premium pendant au moins deux mois.

Avec cette licence, vous pouvez mettre en place un serveur de transit et dépanner votre futur site de production Cloud, y compris le temps nécessaire pour tester toutes les intégrations. Avant, la seule option dont vous disposiez était une version d’essai de 7 jours avec une extension possible via le support Atlassian.

Le seul inconvénient de l’essai de migration étendue est qu’il ne s’applique pas aux applications. Il se peut donc que vous deviez demander séparément aux fournisseurs d’applications une licence similaire.

Le support Atlassian promet une aide supplémentaire au cours du processus de migration si un problème survient, alors assurez-vous de les informer à l’avance.

Un nouveau terme que vous verrez sur Cloud est Organisation. Il s’agit d’un panneau de contrôle global où vous définissez qui peut accéder à quelle application. Vous pouvez également connecter votre annuaire d’utilisateurs à une Organisation pour gérer les utilisateurs Atlassian dans le même domaine. Plus d’informations ici.

Une autre chose à surveiller qui concerne les utilisateurs est le fait que les membres d’un groupe portant le même nom qu’un groupe sur Cloud auront migrés vers le groupe Cloud. Et cela signifie qu’ils obtiendront toutes les autorisations pour Cloud !

Alors que vous migrez de Server, qui n’était peut-être accessible que par un VPN, par exemple, vous voudrez peut-être revérifier vos filtres et tableaux de bord publics et réduire leur visibilité. Plus important encore, examinez l’option Inscription publique qui permet aux utilisateurs de créer leurs propres comptes.

Lorsque vous importez Jira en même temps que Confluence, passez en revue la fonctionnalité « Confluence Cloud Importer » appelée « Jira Macro Repair ». Cette fonctionnalité est utilisée lorsque les macros dans Confluence s’effondrent, lancez-la si vos macros ne fonctionnent pas.

Importation de site ou Assistant de migration ?

En utilisant la méthode Importation de site, vous créerez un fichier de sauvegarde de Server, que vous importerez sur Cloud plus tard. Les fichiers dans les archives doivent être structurés de cette manière :

Si vous disposez d’une grande instance, la bonne pratique consiste à importer les pièces jointes et la sauvegarde XML séparément ou même à diviser les dossiers des pièces jointes/logos/avatars et à les importer en partie. Lisez ce manuel sur la manière de procéder.

Ensuite, vérifiez que les fichiers XML ne contiennent pas d’erreurs spécifiques qui pourraient faire échouer l’importation, comme des caractères non valides, des tâches groupées en double et plus encore. Nous avons inclus ces étapes de révision dans le runbook. Pour corriger ces erreurs, consultez la documentation Importation de site. De plus, l’importation elle-même stagne généralement autour de 50 % et 90 % – c’est normal.

Enfin, créez une copie de votre dossier install + data et une copie de la base de données au cas où.

Regardons le runbook de la migration de Server vers Cloud. Les étapes exclusives à l’Importation de site seront colorées en bleu, tandis que les étapes exclusives à l’Assistant de migration seront colorées en vert.

Si vous ne l’avez pas encore fait, vous pouvez vous procurer cette liste de contrôle en téléchargeant notre feuille de calcul gratuite.

Nous avons donc passé en revue ce qui vous attend après la migration, que ce soit vers Cloud ou vers Server : ce à quoi vous devez vous préparer, qu’il s’agisse des exigences en matière d’utilisateurs, de licences ou de matériel. Nous avons également préparé des listes de contrôle pour les deux types de migration.

Résumé

Le prochain chapitre portera sur les étapes techniques réelles de la création d’une plateforme de transit. Nous impliquerons les utilisateurs dans les tests et nous vous rappellerons ce qu’il ne faut pas oublier une fois la migration effectuée.

Chapitre 4 – Transit, tests et exécution : C’est le moment de migrer votre Jira

Très bien, nous avons planifié la migration de Jira et nous avons passé en revue ce qu’il ne faut pas oublier. Nous allons maintenant mettre en place une instance de transit, indiquer comment les autres utilisateurs pourraient aider et ce qu’il faut préparer une fois que vous avez terminé.

Vous savez ce qu’il faut faire avant, pendant et après la migration de Jira, alors faisons-le.

Mais attention ! Vous devriez d’abord l’essayer sur un serveur de transit.

Dans ce chapitre, nous vous montrerons comment en créer un, et après cela, vous pourrez lire notre scénario de test pour les tests d’acceptation par les utilisateurs. Enfin, nous aborderons le support après migration et les quelques éléments à ne pas oublier lorsqu’elle est terminée.

Transit de la migration Server

Qu’est-ce qu’un serveur de transit ? Et pourquoi l’utiliser, de toute façon ?

Un serveur de transit est une plateforme de test identique à la production future. « Plateforme » peut désigner l’ensemble du serveur d’application (Server) ou au moins l’application (Cloud). En fait, vous devez d’abord tester la migration de Jira ici. Vous découvrirez combien de travail, combien de temps et de temps d’arrêt il faut pour la migration de production proprement dite, et vous découvrirez également diverses erreurs, et comment les prévenir. Alors comment créer un serveur de transit ?

Ci-dessous, nous avons préparé un guide (Méthode d’Importation de site pour Cloud) qui couvre principalement les étapes techniques. Dans un cas complexe, vous devrez peut-être procéder à des vérifications supplémentaires, comme indiqué au chapitre 3.

Migration vers Coud :

1. Créez une sauvegarde du serveur. Sur Server, choisissez System -> Backup System et donnez-lui un nom.
2. Préparez deux fichiers zip.
   • Le premier contiendra les fichiers activeobjects.xml et entities.xml – trouvez-les dans le fichier de sauvegarde de votre serveur dans JIRA_HOME/import. Appelez-le, par ex. « data_import.zip ».
   • Le deuxième contiendra les dossiers JIRA_HOME/attachments, JIRA_HOME/logos et JIRA_HOME/avatars. Appelez celui-là, par ex. « media_import.zip ».
3. Inscrivez-vous pour une instance Cloud ici. Soit :
   • Utilisez une version d’essai régulière pendant 7 jours, extensible grâce au support Atlassian jusqu’à 37 jours.
   • Utilisez un essai de migration étendu pour Jira ou Confluence. Activez-le sur my.atlassian.com.
   • Utilisez une instance de développement gratuite, une instance Cloud gratuite ou un abonnement payant. Toutefois, les deux premiers sont limités en ce qui concerne le nombre d’utilisateurs.
4. Lorsque votre instance est installée, allez à System -> Restore System. Choisissez « Import data » et téléchargez « data_import.zip ». Ensuite, choisissez Import Media et téléchargez « media_import.zip ». L’importateur vous informera de toute erreur avant de procéder.

Test d’acceptation par l’utilisateur

Une fois que l’instance de transit est en ligne et que les principaux problèmes sont résolus (voir le runbook au chapitre 3 pour les plus graves), l’étape suivante consiste à impliquer vos utilisateurs. Les tests d’acceptation par l’utilisateur (UAT) permettent aux administrateurs de déléguer une partie de leur travail et de s’assurer que tout le monde peut utiliser le nouvel environnement sans problème.

De qui ai-je besoin ?

D’une équipe variée. Pour couvrir le plus grand nombre possible d’applications, chaque testeur doit travailler différemment avec l’outil. Le groupe UAT peut inclure :

• • Un utilisateur régulier qui travaille chaque jour avec l’outil
  • Un utilisateur avancé avec des autorisations étendues (disons un PM ou un Scrum Master)
  • Un utilisateur qui travaille avec des parties supplémentaires de l’application (par ex. des applications, des intégrations)
  • Un utilisateur qui reçoit des rapports de l’outil (pour voir si les données qu’il tire sont correctes).

Plus il y a de testeurs, mieux c’est : en règle générale, 5 utilisateurs avec des rôles différents devraient suffire.

Vous pouvez également impliquer vos chefs d’équipe dans l’UAT. Comme une migration modifie considérablement l’aspect de l’application, les responsables voudront très probablement s’impliquer afin que leurs équipes ne se sentent pas perdues après la migration de production. Et si les chefs d’équipe apprennent d’abord le mode d’emploi, ils pourront le transmettre par la suite.

Combien de temps pour les tests ?

Une semaine ou deux devraient suffire pour éliminer les erreurs courantes. Créez un incident Jira pour chaque testeur, connectez-le à une page de cas test dans Confluence et demandez aux utilisateurs de le remplir à mesure qu’ils le testent. Lorsqu’ils ont terminé, ils peuvent donner leurs conclusions à la personne responsable.

Que font-ils ?

Les UAT concernent les fonctionnalités avec lesquelles tout le monde travaille habituellement. Voici un exemple de scénario de test Jira pour vos testeurs (ajoutez-y les caractéristiques spécifiques de votre application). Si les utilisateurs ont des problèmes particuliers, il serait bon de le préciser dans vos supports de formation.

Là encore, vous pouvez télécharger gratuitement la fiche de travail ici.

Migration de la production

Si les UAT se sont bien passés, si toutes les erreurs ont été corrigées, et qu’il n’y a plus rien à faire… Alors c’est le moment.

Il n’y a pas beaucoup de nouveaux éléments techniques qui n’ont pas été couverts. Mais ce qui change, c’est que cette fois, c’est sérieux !

Si vous avez migré vers Cloud, vous n’avez pas besoin de créer un nouveau site. Vous pouvez simplement réinitialiser l’ancien en annulant et en réactivant l’abonnement.

La meilleure façon de procéder à la migration est de la programmer le week-end afin d’avoir suffisamment de temps pour régler les problèmes qui pourraient survenir. Aussi, pour rappel, assurez-vous de :

• Disposer d’un plan de migration et d’un calendrier accessible à toutes les personnes concernées, par exemple l’administrateur DB, l’administrateur du serveur, etc. avec les moyens de les contacter – un numéro de téléphone et un e-mail.
• Mettre une bannière avec une annonce sur l’ancienne instance en envoyant les utilisateurs vers la nouvelle instance.
• Définir les autorisations en lecture seule sur tous les projets/espaces/référentiels.
• Envoyer un e-mail global à tous les utilisateurs le vendredi. Assurez-vous qu’il contienne :
  • Une description de ce qui se passe (Nous allons migrer notre Jira… )
  • Un lien vers la nouvelle instance qu’ils utiliseront à partir de lundi (Le lien pour y accéder est ici…)
  • Qui et comment contacter en cas de problèmes (Pour les questions et les rapports de bug, contactez…)
  • Un résumé des changements, un lien vers les vidéos de formation et la documentation
  • Que tout le travail qu’ils font à partir d’un certain moment (disons vendredi à 18 heures) sera perdu (ce devrait également être le moment de mettre l’application en lecture seule).

Support après migration

Le support après migration consiste à s’assurer que la transition de vos utilisateurs vers la nouvelle instance s’effectue sans difficulté. Et même s’ils rencontrent des problèmes, vous êtes là pour eux !

Dans le message du vendredi, indiquez aux utilisateurs où ils peuvent obtenir de l’aide. C’est très important – sinon, ils pourraient se sentir perdus. Vous pouvez les diriger vers un e-mail de support, mais une meilleure option est de créer un projet Jira dédié au support utilisateur où ils peuvent créer un ticket – même anonymement, si leur compte ne fonctionne pas (n’oubliez pas de définir les autorisations du projet et ce que l’utilisateur anonyme peut voir).

De cette façon, vous mettez en place une future gouvernance efficace des demandes, des bugs et des modifications des outils Atlassian et vous évitez de courir après les e-mails et les appels non documentés.

De nombreux utilisateurs verront la nouvelle application pour la première fois et seront confus. D’autres, qui auraient dû tester l’instance, mais ne l’ont pas fait, rencontreront des problèmes. Ils peuvent avoir un problème avec quelque chose qui a bien fonctionné sur l’ancienne instance, ou même en transit. Ils peuvent même demander l’ensemble des nouvelles fonctionnalités.

La documentation des types de tickets créés permet de résoudre les éventuels malentendus en cours de route. Quoi qu’il en soit, pendant les deux premières semaines suivant l’émigration, assurez-vous que vous êtes prêt à faire face à une charge de travail supplémentaire et que vos ingénieurs Atlassian sont là pour vous aider.

Conclusion

Dans ce guide, j’ai essayé de couvrir tout ce que vous devez prendre en considération avant, pendant et après la migration. Même si vous êtes déjà un utilisateur de Jira, il serait bon de revoir chaque modèle de déploiement avec ses propres avantages et inconvénients afin de faire le meilleur choix avant de migrer Jira. J’ai ensuite passé en revue le processus de préparation où vous devez analyser la nouvelle plateforme et nettoyer votre instance.

Au chapitre 3, la planification étape par étape de la migration de Server vers Cloud a été discutée en détail et une liste de contrôle a également été fournie pour vous aider à migrer plus facilement. Enfin, au dernier chapitre de cet article de la série sur la maintenance de la pile Atlassian, j’ai abordé l’exécution, la mise en place et les tests d’acceptation par l’utilisateur, ainsi que le support après migration.

Voici tout ce que vous devez savoir sur la façon de migrer Jira. Donc, si vous avez bien suivi le guide, je vous félicite pour votre migration réussie !