Migration de Jira à Tuleap : nouvelle fonctionnalité

Posté par  . Édité par Xavier Teyssier, Davy Defaud et Benoît Sibaud. Modéré par Davy Defaud. Licence CC By‑SA.
33
7
nov.
2020
Technologie

Cela faisait un moment que la communauté le demandait, alors l’équipe R & D de Tuleap l’a fait : une importation simple et rapide des issues (tickets, artefacts) de Jira vers Tuleap.

Importer vos données de Jira vers Tuleap

Petit rappel au cas où : Jira et Tuleap sont des solutions de gestion de projet et de suivi des artefacts. En complément d’outils de gestion agile, Tuleap inclut d’autres fonctionnalités pour le développement logiciel collaboratif, la gestion des tests, la gestion des documents, etc.
Jira est propriétaire et sera bientôt uniquement disponible dans le cloud, d’après un communiqué récent. Tuleap est libre (licence GPL), installable sur un serveur ou disponible en tant que service dans le cloud, pour ceux qui ne veulent pas s’occuper de l’installation ou de la maintenance.

Pour ceux qui souhaitent basculer de Jira vers Tuleap, la nouvelle fonctionnalité permet d’importer les tâches, stories et bogues depuis un projet Jira vers un projet Tuleap. En quelques clics, un nouveau tracker Tuleap est créé avec les entrées.

L’importation se déroule en quatre étapes

  1. côté Jira, les utilisateurs rendent leurs adresses de courriel publiquement lisibles (pour que la corrélation entre les utilisateurs puissent être réalisée) ;
  2. depuis Tuleap, l’administrateur du projet Jira importe les issues en créant un nouveau tracker Tuleap dans son projet (on se connecte à l’API Jira via un user API Token et l’adresse de la plate‑forme Jira) ;
  3. Tuleap importe automatiquement en asynchrone les issues en répliquant les données des champs de type texte, chaîne de caractères, date, boîte de sélection, statut, etc., ainsi que les pièces jointes, historique et commentaires ;
  4. Tuleap retrouve les utilisateurs Jira et les utilisateurs Tuleap (créateur, rapporteur, listes d’utilisateurs).

En exemple, voici le résultat sous forme de Kanban des issues Jira importées dans Tuleap

Kanban des issues importées depuis Jira dans Tuleap

Si vous avez besoin d’aide, vous pouvez posez vos questions dans la messagerie instantanée de la communauté Tuleap.

Aller plus loin

  • # Précisions

    Posté par  . Évalué à 7.

    Jira est propriétaire et sera bientôt uniquement disponible dans le cloud, d’après un communiqué récent.

    La version "Server" effectivement, mais pas la version "Datacenter" (qui coute évidemment une tonne et qui est totalement inabordable pour une startup/PME).

    Ça n'en reste pas moins un changement qui va pousser BEAUCOUP d'utiliseurs à chercher des solutions de remplacement, et heureusement pour Jira il y en a pas mal… comme Tuleap par exemple, même si la possibilité de customisation des workflows de Jira (donc pour faire autre chose que de gérer des projets de développement software : c'est sa plus grande force mais aussi sa plus grande faiblesse puisqu'on facilement en faire un monstre :-) est à l'heure actuelle assez inégalée.

    Gitlab l'a aussi bien compris et prends le contrepieds en basculant plein de fonctionnalités payantes dans la version "core" (free) :-)

    C'est malheureusement aussi le cas de Confluence, autre produit d'Atlassian à laquelle je n'ai jamais vraiment trouvé d'alternative utilisables en entreprise… (c'est à dire y compris par des personnes 'non techniques' à qui vous n'allez pas faire faire du markdown…).
    Il y a aussi un écosystème de plugins gigantesque…

    Ce changement de politique est très pénible, d'autant que Confluence est souvent utilisé pour conserver de la propriété intellectuelle qu'on n'a pas forcément envie de voir se retrouver sur les serveurs de nos amis américains (donc hors de question d'utiliser l'offre cloud).

    • [^] # Re: Précisions

      Posté par  (site web personnel) . Évalué à 1.

      La force aussi de Jira, Confluence, Bitucket Server, c'est aussi leur facilité de maintenance.

      Ca fait un bail que j'utilise les 3 (à l'époque Bitbucket Server s'appelait Stash) et pour moi leur force, c'est aussi l'intégration entre ces trois outils.

      Est-ce que cela va pousser beaucoup d'utilisateurs vers d'autres produits? Je suis septique.
      Lorsque je vois le nombre grandissant d'entreprises qui passent ou cloud pour ce genre d'outil car ce sont plein de soucis de maintenance en moins.

      Perso, j'hésite entre Azure Devops (anciennement visualstudio.com) et le cloud Atlassian.
      Le truc c'est que pour le second, des plugins free en mode serveur sont payant en mode cloud.

    • [^] # Re: Précisions

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Est-ce que XWiki pourrait remplacer Confluence, et sinon, qu'est-ce qui lui manque? Ça a l'air assez similaire mais j'ai peu utilisé Confluence et pas du tout XWiki pour l'instant.

      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 1.

        Cela fait 6 ans que je n'ai pas touché à xwiki.

        Personnellement, je crée des références entre Confluence et Jira dans les pages/tickets.
        (sans compter les références auto-liées. Si je met un numéro d'issue dans un message de commit, le numéro de commit apparait sur l'issue dans Jira)

        Confluence et Bitbucket Server répliquent l'annuaires des utilisateurs Jira (Jira devient en quelque sorte un mini Atlassian Crowd).

        Si je devais prendre des outils séparés, quelle serait leur intégration entre eux ? Je devrais mettre en place un annuaire type ldap/ad pour la gestion des utilisateurs transversalement à tous les outils.

        Sans compter dans Jira la puissance des workflow. Ca c'est la killer feature.

        Mais en 6 ans d'utilisation des outils Atlassian, je me rend compte maintenant le gain de temps énorme en maintenance que cette solution m'a offert.

        Je ne pense pas retrouver quelque chose d'équivalent ailleurs.

      • [^] # Re: Précisions

        Posté par  . Évalué à 1.

        XWiki est une piste clairement, surtout qu'il est encore pas mal maintenu et développé (par des français d'ailleurs il me semble!) et qu'ils sont intervenus dans les chats/forums mis en place au moment de ces annonces pourries d'Atlassian par des utilisateurs de confluence dégoutés qui cherchent une solution de repli :-)

        Il y a aussi wiki.js qui est très prometteur.

        Une des killer features de Confluence c'est la possibilité d'éditer une page en même temps à plusieurs (un peu comme comme google-doc & google-spreadhseets, qui déchirent quand même pas mal sur ce point il faut bien l'avouer).

        Et c'est vraiment blindés de plugins divers et variés.
        On utilise énormément ces deux la :
        https://www.k15t.com/software/scroll-pdf-exporter
        https://www.k15t.com/software/scroll-word-exporter

        Qui sont ultra configurables à travers une gui bien foutue et qui génèrent des docs vraiment clean à partir d'arborescence confluence.

        Ça permet de transformer un ensemble de pages Confluence écrite à l'arrache en proposition commerciale ou en documentation cliente (par exemple) en 2 secondes. C'est franchement très pratiques.

        A noter quand même qu'Atlassian arrêtera des vendre des licences "server" après février 2021 (de mémoire) mais continuera toujours de supporter des licences en cours.

        Il reste donc encore la possibilité de prendre une license pour 3 ans avant février 2021 si le support est important (puisqu'il ne faudra plus compter sur des nouvelles features…)

        Sinon… Une license expirée reste valide (le soft continue de tourner) il ne permet juste plus de faire de mise à jour. Mais bon ça reste un peu flippant.

        Je caresse encore l'espoir qu'une bronca générale les fasses reculer mais je comprends que les sirènes du modèle clouds/SaaS avec sa facturation récurrente par user/mois soient très fortes.

    • [^] # Re: Précisions

      Posté par  . Évalué à 2.

      la possibilité de customisation des workflows de Jira (donc pour faire autre chose que de gérer des projets de développement software)

      Avec Tuleap, vous allez pouvoir créer des trackers pour suivre n'importe quoi. Chez Enalean par exemple, on suit nos demandes clients, nos tâches administratives, nos congés avec des trackers Tuleap et workflow configurés pour cela. Ou encore, nos clients créent des trackers différents et bien spécifiques pour gérer à la fois leur projets hardware et software en parallèle.

      • [^] # Re: Précisions

        Posté par  . Évalué à 1.

        Intéressant, je vais regarder de plus près!

        Par contre le non support de postgresql (et la volonté visiblement affichée de ne PAS le supporter) mentionné dans un autre commentaire m'inquiète un peu.

        J'imagine que les interactions avec le SGBD se font quand même très majoritairement à travers un ORM donc le support de divers SGBD ne devrait pas être un problème…
        Ou est-ce que justement Tuleap a réinventé la roue avec ses propres wrapper pour causer avec mysql ?

  • # Pertes

    Posté par  . Évalué à 4.

    Comment sont gérés les pertes ? Ce qui ne peux pas être reproduit dans tuleap ?

    Jira (que je n'utilise plus depuis pas mal de temps) et surtout intéressant s'il est beaucoup customisé :

    • la création de rapport (et de mon souvenir c'est siffisament chiant à faire pour ne pas trop vouloir y revenir)
    • création workflow avec tout ce qui va avec comme gestion des rôles et gestion de formulaires pour chaque étapes du workflow
    • l'utilisation de divers plugin
    • la possibilité de scripter pas mal de chose en groovy (par exemple pour ajouter un champ calculé qui pourra ensuite être pris en compte dans les workflow)

    Je me doute que tuleap ne reproduit pas tout (c'est même pas forcément souhaitable).

    Est-ce qu'il est possible de :

    • faire du dry-run, rollback ou une quelconque manière de revenir en arrière pour s'y retrouver ?
    • avoir un listing de tout ce qui n'est pas importé pour pouvoir le gérer d'une manière ou d'une autre ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Pertes

      Posté par  (site web personnel) . Évalué à 4.

      Comment sont gérés les pertes ? Ce qui ne peux pas être reproduit dans tuleap ?

      Pour le moment nous nous sommes concentrés sur l'import des données.
      Ce qui ne peut pas être importé est ignoré, principalement pour éviter d'avoir des commentaires remplis de texte imbitable (data en vrac). Par contre on est preneurs de propositions sur le sujet de la part d'experts Jira.

      Toute migration d'un outil à un autre nécessite de repenser une partie du workflow que l'on utilise (il y a des choses que l'on fait parce que l'outil nous oblige à fonctionner d'une certain façon) donc notre ambition n'est pas de faire l'import fonctionnel le + fidèle mais surtout de garder le + de données possible.

      • la création de rapport (et de mon souvenir c'est siffisament chiant à faire pour ne pas trop vouloir y revenir)

      A l'heure actuelle, seuls les rapports par défaut sont importés. Les rapports sont assez facile à construire côté Tuleap donc ça peut être un compromis acceptable. Cela dit, on manque d'exemples probants de rapports pour essayer de les importer.

      • création workflow avec tout ce qui va avec comme gestion des rôles et gestion de formulaires pour chaque étapes du workflow

      On n'importe le status et ses valeurs historisées concernant le workflow, pas la configuration. Je ne suis même pas sur qu'on soit capable d'avoir toute la config su WF par les APIs.

      • l'utilisation de divers plugin

      Pas de plugins pour le moment.

      • la possibilité de scripter pas mal de chose en groovy (par exemple pour ajouter un champ calculé qui pourra ensuite être pris en compte dans les workflow)

      Pareil, pas d'import d'autre chose que les datas.

      • faire du dry-run, rollback ou une quelconque manière de revenir en arrière pour s'y retrouver ?

      C'est un import sur la base des APIs de Jira donc vous pouvez faire autant d'essais que vous le souhaitez, détruire ensuite l'import et recommencer.

      • avoir un listing de tout ce qui n'est pas importé pour pouvoir le gérer d'une manière ou d'une autre ?

      Je ne suis pas certain que ça soit réalisable car la construction actuelle c'est que l'on "décide" de ce que l'on va importer (ex les reports par défaut) et on cherche comment cette info est accessible via les APIs de Jira. Ce n'est pas comme si on avait un export complet (genre un dump XML de l'intégralité des issues) et que l'on dise "ce truc là ça va devenir ça, etc).

      Pour que quelque chose soit importable il faut:
      * que l'on sache que la fonctionnalité existe
      * qu'elle soit représentée dans l'API REST
      * que le jeu en vaille la chandelle :)

  • # Tuleap en 2020 ?

    Posté par  (site web personnel) . Évalué à -1.

    Il y a deux ans, j'avais fait une installation de test. Rien que la partie mise en place du docker tuleap a été une vrai galère. Ca m'a pris 2 jrs à configurer chercher des configs pour mon besoin sur le net.

    J'espère qu'en 2 ans le système a été amélioré. Ne pas pouvoir l'installer simplement et le configurer facilement sur un proxypass et un énorme frein.

    J'ai mis tout mes services (en dehors des Atlassian) dans des containeurs. Je ne pense pas un jour revenir à un mode "traditionnel" d'installation de services.

    Est-ce que la partie wiki de tuleap permet un export pdf ?

    • [^] # Re: Tuleap en 2020 ?

      Posté par  . Évalué à 2.

      Si vous avez d'aide pour vos installations, le mieux et le plus rapide est de poser vos questions à la communauté : https://chat.tuleap.org/

    • [^] # Re: Tuleap en 2020 ?

      Posté par  (site web personnel) . Évalué à 2.

      Il y a deux ans, j'avais fait une installation de test. Rien que la partie mise en place du docker tuleap a été une vrai galère. Ca m'a pris 2 jrs à configurer chercher des configs pour mon besoin sur le net.

      Pour les problèmes d'install, comme dit avant https://chat.tuleap.org

      L'image docker publique est + à des fins de démo/test, il n'est pas recommandé de l'utiliser en production. Il y a une image officielle de prod mais uniquement pour Tuleap Entreprise pour le moment.

      Est-ce que la partie wiki de tuleap permet un export pdf ?

      Oui

      • [^] # Re: Tuleap en 2020 ?

        Posté par  (site web personnel) . Évalué à 0.

        C'est dommage pour la version communautaire et docker. Après je comprend que pour le business, il est plus utile de fournir des facilités pour le monde pro ;)

  • # À propos de la stack

    Posté par  . Évalué à 1.

    J'ai cherché le code … pour comparer avec Jira en Java, Redmine et Gitlab en Ruby

    Il est sur un dépôt privé https://docs.tuleap.org/developer-guide/quick-start/clone-tuleap.html

    Le backend c'est … du PHP / MySQL !!! https://docs.tuleap.org/developer-guide/back-end.html
    Le frontend ils ont compris que AngularJS c'est … et maintenant ça doit être Vue.js https://docs.tuleap.org/developer-guide/front-end.html

    voir aussi https://docs.tuleap.org/deploy.html

    • [^] # Re: À propos de la stack

      Posté par  (site web personnel) . Évalué à 2.

      Le backend c'est … du PHP / MySQL !!! https://docs.tuleap.org/developer-guide/back-end.html

      Yep, je confirme.

      Le frontend ils ont compris que AngularJS c'est … et maintenant ça doit être Vue.js https://docs.tuleap.org/developer-guide/front-end.html

      Oui oui, je confirme qu'on a bien compris. Tous les nouveaux devs sont en Vue.js et on migre progressivement les anciens devs AngularJS.

      • [^] # Re: À propos de la stack

        Posté par  (site web personnel) . Évalué à 0.

        Je n'ai pas vu dans la doc après une recherche une page qui parle de postgresql.

        • [^] # Re: À propos de la stack

          Posté par  (site web personnel) . Évalué à 2.

          PostgreSQL n'a jamais été supporté (et pas de support prévu).

          • [^] # Re: À propos de la stack

            Posté par  . Évalué à 3.

            Ouille… ça pour moi c'est game over.

            • [^] # Re: À propos de la stack

              Posté par  (site web personnel) . Évalué à 6.

              C'est dommage :)

              Pour aller plus loin et répondre en parallèle à votre commentaire plus haut sur le pourquoi du comment :

              Nous avons fait le choix de ne supporter qu'un seul moteur de DB (en fait MariaDB est compatible mais en vrai on a jamais eu de retour en prod à grande échelle) pour simplifier les problématiques de déploiement. Faire du On Prem c'est très compliqué, même avec des choix franchement clivants (1 seule version de PHP, 1 seule version de MySQL, 2 versions du même OS) ça représente un coût significatif de maintenance (exemple on attend ardemment la mort de RHEL6 dans 20 jours pour enfin pouvoir mettre à jour mediawiki). Ce temps, nous préférons le consacrer à du fonctionnel pour l'utilisateur final.

              Nous avons également fait le choix de le pas utiliser d'ORM. En premier lieu parce qu'un ORM pour 1 seul moteur de DB c'est un peu overkill et en plus car le modèle de données des trackers (l'équivalent de Jira chez atlassian) est extrêmement complexe et, de tout façon il aurait fallu faire du by pass et écrire les requêtes à la main.

              Le gros avantage c'est que l'on a la maîtrise complète de bout en bout et on a des perfs sur lesquels on a pas à rougir. Ça me fait un peu marrer la limite à 2000 utilisateurs des instances Jira on Prem quand on à 45'000 utilisateurs sur certaines des nôtres avec juste une séparation web serveur et DB (pas de cluster ou quoique ce soit de monstrueux, et des serveurs "standards").

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.