- Retour d’expérience sur un projet open source de migration de Jira vers GitLab
- Déclencheur
- Annonce de la fin du support des produits Jira Server à partir du 15 février 2024
- Alternatives possibles : Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub, etc.
- Que faire pour ceux qui utilisaient Jira Server ? Pourquoi ne pas créer un projet de migration vers GitLab ?
- État des fonctionnalités de migration Jira → GitLab
- Dans GitLab, copie du
title, de la description et des label des issues Jira
- Le reste des métadonnées est importé dans la
description
- Fournit une interface pour faire correspondre les utilisateurs Jira aux utilisateurs GitLab
- Limitations de la migration Jira → GitLab
- Configuration de l’intégration Jira obligatoire
- Seule l’API Jira v3 est disponible
- Jira et GitLab utilisent des syntaxes différentes, donc la migration n’est pas exacte
- Dans la
description, Heading 1, Heading 2, Heading 3 sont transférés en Numbered, SubNumbered, SubNembered 2
- GitLab utilise la syntaxe Markdown, tandis que Jira utilise son propre format
ADF (Atlassian Document Format), d’où cette différence
- Les
issue type, priority et label ne sont pas non plus migrés avec précision
- Orientation du projet de migration interne
- Objectifs :
- Prendre une décision sur la destination des epics Jira et des issues
- Définir précisément vers quels champs GitLab doivent être migrés les champs Jira comme
title, description, label, component, etc.
- Lors de la migration des epics Jira vers des epics GitLab, laisser à l’utilisateur la liberté de choisir entre une migration vers des sous-epics dans un sous-groupe ou vers des epics dans un groupe parent
- Les issues sont migrées comme des issues
- Limites :
- On voulait aussi migrer les sous-tâches Jira vers des tâches sous des issues, mais l’API des tâches de GitLab ne le prend pas en charge
- Jira a trop de champs ;
- Les fonctions simples comme
description, label, component sont aussi prises en charge dans GitLab, donc elles peuvent être migrées
- Mais !!! les champs liés au
time tracking et à la sécurité ne sont pas pris en charge par GitLab, donc ils ne peuvent pas être migrés
- Schéma de conception final
- Projet Jira → projet GitLab
- Epic Jira → epic GitLab
- Issue Jira → issue GitLab
- Les
title, description, version, story point, resolution de Jira sont mappés tels quels dans GitLab
Jira resolution → GitLab closed, Jira story point → GitLab weightJira issue type, component, status, priority → migration à l’aide de label et de scoped label GitLab- Développement également de
custom field
- La
description est entièrement analysée avec des expressions régulières, puis le contenu est converti en Markdown avant migration
- Résultats du projet
- La migration du mode standard de Jira est exploitable
- En dehors des plugins et des automatisations, la migration fonctionne bien
- La plupart des éléments sont mappés avec des labels GitLab
- Création des epics dans le groupe parent cible
- Les liens entre issues définis dans Jira sont aussi migrés vers GitLab
- Le wiki markup Jira est converti via un convertisseur Markdown
- Ajout également des pièces jointes et des commentaires aux issues
- Plus on crée de
custom field, plus la migration devient difficile
- Points réussis
- La version cloud a été créée d’abord, puis le support serveur a été ajouté
- En configurant seulement le mapping des
custom field, il est possible de réaliser la plupart des migrations
- Grâce à une bonne mise en place du traitement parallèle, la migration est devenue plus de 3 fois plus rapide qu’en son absence
- La configuration est gérée en YAML, en phase avec les tendances actuelles
- Le projet a été publié en open source pour que tout le monde puisse migrer
- Le package est distribué via Brew
- Points à améliorer
- Lors d’une migration depuis Jira Server
- Un mapping des sprints est en plus nécessaire
- Il n’existe pas de solution pour les champs Cascade
- Lors d’une migration depuis Jira Cloud
- Il faut tester de nombreux cas réels, notamment la migration des données liées aux plugins
- Page du projet open source :
Aucun commentaire pour le moment.