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 :)
[^] # Re: Pertes
Posté par vaceletm . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 4.
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.
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.
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.
Pas de plugins pour le moment.
Pareil, pas d'import d'autre chose que les datas.
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.
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 :)