MantisBT est un traqueur de bugs historique, apprécié pour sa simplicité et sa gratuité, mais aujourd’hui dépassé : il vit en dehors de l’écosystème de développement moderne, loin du code, des pull requests et du CI/CD. GitHub Issues inverse la logique en plaçant le suivi des bugs au cœur du dépôt, là où travaillent les développeurs. Migrer de MantisBT à GitHub Issues, c’est rapprocher le ticket de la ligne de code qui le corrige — à condition de réussir une reprise fidèle de l’historique des anomalies.
Pourquoi migrer de MantisBT vers GitHub Issues ?
Le bénéfice central est la proximité avec le code source. Dans GitHub Issues, un bug est un issue directement liée au dépôt : on peut le référencer dans un commit, le fermer automatiquement via une pull request, le relier à un milestone, l’enrichir de labels et l’intégrer aux project boards et à Actions. Cette unification élimine la double saisie entre le traqueur et l’outil de versionnement, accélère la boucle de correction et donne aux développeurs une visibilité immédiate. Pour une équipe déjà sur GitHub, c’est aussi la fin d’un outil de plus à maintenir.
Différences concrètes entre MantisBT et GitHub Issues
| Dimension | MantisBT | GitHub Issues |
|---|---|---|
| Modèle | Traqueur de bugs autonome | Issues intégrées au dépôt Git |
| Liaison code | Aucune (ou via plugins) | Native (commits, PR, fermeture auto) |
| Données | Bugs, notes, pièces jointes, relations | Issues, commentaires, labels, milestones |
| Personnalisation | Champs personnalisés, catégories | Labels, templates, projets |
| Automatisation | Limitée | Actions, workflows |
Les étapes de la migration
- Audit de MantisBT : recenser les bugs, notes, pièces jointes, catégories, statuts, priorités, relations entre tickets, utilisateurs et champs personnalisés.
- Nettoyage des données : clôturer les bugs obsolètes, dédupliquer les tickets, archiver les projets abandonnés.
- Cartographie des objets : mapper les statuts et priorités MantisBT vers les labels GitHub (bug, enhancement, priority), et les catégories vers des labels dédiés.
- Extraction : exporter les données depuis la base MySQL de MantisBT ou via son API, en isolant chaque bug, ses notes, ses pièces jointes et ses relations.
- Transformation : convertir les enregistrements au format attendu par l’API GitHub Issues, en reconstruisant l’historique sous forme de commentaires et en transférant les pièces jointes.
- Import : injecter les issues dans le dépôt GitHub via l’API REST (
POST /repos/{owner}/{repo}/issues), en séquençant pour préserver les références entre issues. - Reconfiguration : créer les labels, templates d’issue, milestones et project boards, et configurer les automatisations (fermeture automatique, workflows).
- Test et bascule : valider l’intégrité sur un dépôt de test, former les équipes, puis basculer avec MantisBT en lecture seule.
Les pièges à éviter
Le premier risque est la perte des relations entre tickets : dans MantisBT, un bug peut être lié à un autre (duplicata, parent, dépendance) ; ces liens doivent être reconstruits sous forme de références croisées dans les issues, sous peine de perdre une partie de la connaissance. Le deuxième est la gestion des pièces jointes : captures d’écran et fichiers joints doivent être ré-importés et re-liés aux bonnes issues. Le troisième est l’appauvrissement des champs : MantisBT permet des champs personnalisés qui n’ont pas d’équivalent direct dans GitHub Issues ; ils doivent être convertis en labels ou en sections du corps de l’issue, en acceptant une simplification assumée.
Bonnes pratiques pour une bascule réussie
- Définir la convention de labels avant l’import : une taxonomie claire (type, priorité, composant) rend le backlog lisible dès le premier jour.
- Réaliser une migration pilote sur un échantillon pour valider le mapping et les durées.
- Préserver les références et la chronologie des commentaires pour ne pas perdre le contexte des discussions techniques.
- Conserver MantisBT en lecture seule jusqu’à validation complète, puis l’archiver.
- Documenter le nouveau flux de travail (issue → branche → pull request → fermeture) pour que l’équipe l’adopte.
L’impact sur le cycle de développement
Cette migration modifie en profondeur la façon de travailler : le bug n’est plus une entrée isolée dans un traqueur, mais un objet vivant du dépôt, traçable du signalement à la correction. Les développeurs gagnent en contexte, les responsables en visibilité, et la boucle « signaler, corriger, déployer » se raccourcit nettement.
Reprise des bugs, notes et relations
Le cœur de la migration est la reprise des bugs MantisBT avec tout leur contexte : notes, pièces jointes, relations entre tickets, catégories, statuts et priorités. Chaque bug doit être exporté depuis la base MySQL de MantisBT, avec ses commentaires et leurs auteurs, puis réinjecté dans GitHub Issues en reconstituant l’historique sous forme de commentaires. Les relations entre tickets (duplicata, parent, dépendance) se transposent en références croisées dans le corps des issues, en préservant les identifiants pour maintenir la traçabilité.
Les champs personnalisés de MantisBT n’ont pas d’équivalent direct dans GitHub Issues : ils se convertissent en labels (pour les valeurs énumérées) ou en sections du corps de l’issue (pour le texte libre), en acceptant une simplification assumée. Les catégories deviennent des labels de composant, et les statuts/priorités se mappent vers les labels conventionnels (bug, enhancement, priority:high). Une taxonomie de labels claire, définie avant l’import, rend le backlog lisible dès le premier jour.
Gérer les pièces jointes et l’historique des discussions
Les pièces jointes — captures d’écran, fichiers de log, correctifs — doivent être ré-importées et re-liées aux bonnes issues, car elles portent souvent l’information décisive d’un bug. Les discussions techniques dans les notes doivent être conservées avec leur chronologie et leurs auteurs, car elles documentent le raisonnement de résolution. Enfin, les références de versions et de jalons MantisBT se transposent en milestones GitHub, et les projets MantisBT en dépôts ou en labels de périmètre.
Configurer le flux moderne et mesurer la bascule
La migration est l’occasion d’activer le flux moderne : issue → branche → pull request → fermeture automatique, avec des templates d’issue, un project board et des workflows Actions. Ce flux doit être défini avec les développeurs puis documenté. Le succès se mesure par la concordance des compteurs de bugs, de notes et de pièces jointes entre MantisBT et GitHub, et par la continuité du suivi : chaque bug historique reste consultable et chaque nouveau signalement suit le nouveau parcours. Une migration pilote sur un échantillon de bugs, suivie d’une bascule avec MantisBT en lecture seule pour consultation et repli, sécurise l’opération ; la formation des développeurs au nouveau flux achève de garantir l’adoption et la disparition de la double saisie.
Performances Digital accompagne la migration MantisBT vers GitHub Issues : extraction et transformation des bugs, reprise des pièces jointes et des relations, configuration des labels et workflows, formation des équipes. Nous visons un rapprochement complet du suivi des bugs et du code source, sans perte d’historique.
Migrer de MantisBT à GitHub Issues, c’est mettre le ticket au service du code. Demandez votre devis gratuit : nous auditons votre volume de bugs, vos relations entre tickets et vos processus, puis nous vous remettons un plan de migration chiffré, adapté à vos dépôts.
