Étude de cas : Migration de Jira Server vers Jira Cloud

Depuis l’annonce d’Atlassian concernant l’arrêt du développement de Jira Server,
de nombreuses entreprises passent à Jira Cloud ou à Jira Data Center (ou se tournent vers des produits alternatifs).

Nous avons eu l’occasion d’effectuer de nombreuses mises à niveau et migrations de ce type pour nos clients.
Nous avons récemment décidé de partager ici les défis rencontrés en cours de route, nos conclusions et les leçons apprises,
afin que vous puissiez vous en servir pour préparer une transition similaire, que vous l’effectuiez seuls ou avec l’aide d’une entreprise spécialisée.

logo jira cloud

Les défis rencontrés en chemin :

  • Examen de l’adéquation : Jira Cloud est-il l’outil approprié ? La multi-location (Multi-tenancy) est-elle vraiment la bonne solution ?
    Cela implique une perte potentielle de contrôle et de confidentialité.
  • Le transfert des données (data).
  • Tests : Les flux de travail (flows) existants seront-ils pris en charge ?
  • La question des plugins. Certains sont supportés et d’autres non – cela nécessite une vérification approfondie.
  • Il existe plusieurs méthodes pour effectuer la migration. Le défi est de choisir la plus adaptée.
  • Intégrations – Continueront-elles de fonctionner ? (ex : SSO, LDAP, git / GitLab / GitHub, API, webhooks).
  • Les fichiers externes !
  • Fonctionnalités qui pourraient être perdues / options non supportées / changements de comportement fonctionnel.
  • La nécessité de mettre à jour Jira Server si la version est trop ancienne (une condition préalable obligatoire avant de passer à Jira Cloud !).
  • Choix du moment pour l’arrêt de service (downtime), parfois il y en a plusieurs.
  • Quel type de licence conviendra ? Il y a plusieurs options (Standard / Premium / Enterprise / Data Center).
  • Les scripts existants (comme ceux écrits avec Script Runner) – des modifications seront probablement nécessaires.
  • La coopération nécessaire de la part du client.
  • Examen des aspects informatiques (IT).
  • Examen des aspects de sécurité (un domaine distinct dans lequel nous ne sommes pas spécialisés, mais qui est crucial).
  • Il est très probable qu’il y ait des obstacles imprévus en cours de route. Il est très difficile d’estimer à l’avance combien de temps prendra un tel projet, surtout si la personne qui a construit l’environnement ne travaille plus dans l’organisation.
Note : Les défis sont résumés ici. Pour obtenir une liste détaillée des défis, contactez-nous par email à jira@almtoolbox.com.

Conclusions et bonnes pratiques pour une bonne gestion :

  • Considérer cela comme un véritable “Projet” – dans le sens où c’est un sujet qui nécessite de l’attention et de la réflexion de la part de plusieurs parties prenantes dans l’organisation. Ce n’est pas nécessairement quelque chose que l’on fait “au fil de l’eau”.
  • Établir un plan de travail. Cartographier les risques et les conséquences pour comprendre comment les minimiser. Cartographier tous les plugins et toutes les étapes de la migration.
  • Créer un projet dans Jira Cloud pour tester la migration et effectuer une migration “à blanc” (dry run). En fait, il est aussi possible d’ouvrir un projet gratuit de ce type, mais il est recommandé de le faire d’une manière spécifique (pour plus de détails, contactez-nous – voir ci-dessous).
  • Un responsable côté client est nécessaire – il faut un engagement (commitment).
  • Tester, vérifier et encore tester…
  • C’est un projet qui nécessite une expertise en la matière, ainsi que de la patience – cela peut prendre des mois (au total).
    Nous avons rencontré de nombreuses entreprises qui ont externalisé cela à une société spécialisée (comme la nôtre), mais nous avons aussi vu des entreprises le faire seules (généralement dans des cas d’installations simples, non complexes et avec peu d’utilisateurs finaux).
  • Nous avons appris que bien que le fabricant propose des outils de migration gratuits, ils ne fonctionnent souvent pas vraiment.
    D’après notre expérience, ils ne fonctionnent que pour des organisations de 10 à 20 personnes
    et uniquement dans des environnements “vanilla” (standard) qui n’ont pas subi de changements – c’est-à-dire
    qu’ils ne fonctionneront pas si vous avez fait des changements de configuration, du “sur-mesure” ou ajouté des plugins.
    Ces outils de migration échoueront généralement dans des environnements complexes ou modifiés.
Note : Les conclusions sont résumées ici. Pour obtenir le détail complet des défis et des conclusions, contactez-nous par email à jira@almtoolbox.com.

Comment pouvons-nous vous aider ?

Nous sommes spécialisés en ALM, DevOps, Jira, processus de développement et outils complémentaires.
Voici quelques exemples de la manière dont nous pouvons vous aider dans le cadre d’un passage au Cloud :

  • Examen des implications de la migration (Découverte / audit).
  • Planification de la migration + Exécution.
  • Examen du passage à des outils alternatifs.
  • Nous avons une expertise particulière concernant la connexion avec les outils basés sur git (comme Bitbucket / GitHub / GitLab),
    les processus de développement et les développements par-dessus comme Script Runner et les API / hooks.
  • Aide au choix de la licence la plus adaptée aux besoins de l’organisation (et vente de licences à des conditions attractives).

Pour nous contacter : jira@almtoolbox.com ou par téléphone : 01 84 17 53 28

Liens pertinents :

Atlassian abandonne HipChat et Stride , quelle suite ?

atlassian-and-slack
Le week-end dernier a été tumultueux dans le segment des fabricants d’outils pour les sociétés de développement de logiciels
Atlassian (fabricant de produits HipChat, Stride, Jira et plus) a annoncé mardi qu’il vendait à la fois ses produits HipChat et Stride à Slack, ainsi que d’aider ses utilisateurs à passer à
Slack, ce qui signifie que les produits ci-dessus sont très proches de la fin leurs vies
L’annonce intervient après le lancement du produit Stride il y a près d’un an, l’annonçant
comme la nouvelle solution recommandée pour l’ancien produit HipChat et encourageant les utilisateurs de HipChat à y passer
L’annonce intervient même après un mois intense d’annonces et d’annonces de fabricants de produits similaires
Atlasian a déclaré hier que le marché de ces outils (outils de messagerie et de partage des connaissances) est trop saturé à leur avis, et a admis qu’ils n’avaient pas été en mesure de rivaliser avec le taux de croissance de Slack parmi les utilisateurs et les organisations qui autorisent la connexion Internet (utilisateurs SaaS). À la connaissance de beaucoup (et aussi à mon avis), ils semblent avoir simplement abandonné et largué le produit et les utilisateurs

En effet, les réactions vives ne se sont pas fait attendre (lien vers l’une d’entre elles, dans le forum des utilisateurs Atlassian,  en fin de post)
.Les gens ont dit qu’ils venaient de terminer une longue migration vers Hipchat

Quelqu’un a décrit que jusqu’à ce qu’il réussisse à convaincre les utilisateurs de son entreprise de passer à Hipchat – et d’y déplacer toute l’organisation – ils abdandonnent  maintenant le produit et lui ont demandé avec colère ce qu’il était censé

 Pourquoi cette colere?

Atlasian recommande aux utilisateurs de passer à Slack.
La transition n’est apparemment pas trop complexe… mais il y a un gros problème :

Slack ne fonctionne pas sur site, c’est-à-dire que si vous avez un serveur HipChat ou un centre de données HipChat, Atlasian ne vous propose pas de solution !

Alors que font ceux qui ont besoin d’une solution on-premises ?

Il existe une alternative !
.Il existe un produit gratuit et open source appelé Mattermost
Nous le connaissons depuis plus d’un an maintenant, car il fait partie de l’installation de GitLab et nous avons déjà essayé de l’installer et de l’utiliser plusieurs fois
20160315_v210

En effet, ce produit présente les avantages suivants :

  • Il est proposé comme solution d’installation sur site derrière un pare-feu, même pour un réseau fermé non connecté à Internet.
  • Il existe une possibilité de migration depuis HipChat et Stride
  • Permet le partage de messages et de messages – à l’intérieur et à l’extérieur de l’organisation (comme les clients), par groupes et canaux (similaire à Slack)
  • Permet le partage de fichiers entre les utilisateurs
  • Le produit est intégré aux produits Atlassian – en particulier Confluence, Jira et Bitbucket
  • Intégration avec les principaux outils tels que GitLab, Jenkins, GitHub et plus
  • Il existe des applications pour Android et iPhone (vous pouvez donc communiquer avec d’autres personnes même en dehors du bureau… et pratiquement partout)
  • Il s’agit d’un produit open source qui offre également un support fabricant et un support pour les fonctionnalités de réseau d’entreprise
  • Il existe un support pour les bots (utile pour ChatOps)
  • Il existe une API (basée sur REST) ​​ainsi qu’une option pour exécuter des commandes CLI à des fins d’automatisation
  • Le produit met l’accent sur la sécurité et la sûreté
  • Le produit a une documentation complète et riche
Vous voulez recevoir des mises à jour futures sur Mattermost ? Envoyez un e-mail à l’adresse e-mail suivante : Mattermost@almtoolbox.com
Nous promettons de ne pas envoyer de SPAM !

Courte vidéo sur le  produit

Nous offrons une assistance pour le produit Mattermost – qui comprend l’installation, la migration à partir d’autres outils, des instructions sur l’utilisation et la vente d’une licence si nécessaire.
Nous fournissons également des conseils et des licences pour des outils d’intégration, tels que Jira, Confluence, Jenkins, Bitbucket, GitLab et plus encore, et aidons nos clients à économiser de l’argent sur les licences, à éviter les licences excessives et à acheter des licences incorrectes.
Pour plus de détails vous pouvez nous contacter par téléphone 33 1 84 173 63 28 ou par email devops.fr@almtoolbox.com