我的公司两年前开始使用JIRA进行问题跟踪，从那以后我们一直在努力优化工作流程。主要问题是我们有不同产品之间共享的许多模块和库，而JIRA有项目的“孤岛”视图。基本上，JIRA可以从“客户项目”的角度来跟踪问题，但我开始认为它对于“后端开发”的观点越来越无用。
JIRA的组件不能满足我的需求，因为模块或库的开发人员无法将不同项目中出现的问题与她的模块相关联，并将它们分配给它的不同版本。我需要的是项目层次结构，其中较高（产品）级别项目中的组件与较低（模块）级别的另一项目相关。
Atlassian似乎不愿意（无法？）向JIRA添加这样的功能，尽管有许多相关问题可追溯到9年前。转移到另一个问题跟踪具有此功能的软件（如果存在）目前对我们来说是不可行的。
从Atlassian的JIRA系统相关问题的回复数量来看，我们不能成为唯一一个有这个问题的公司，所以我想知道其他人在做些什么来绕过它。
我目前的计划是使用产品项目的组件，并在相关模块/库项目中自动创建和链接组件问题的克隆。克隆是次优的，因为它们不像我想的那样与原始链接紧密相关，并且它们使系统中的问题数量增加一倍（或者更多，如果模块项目中的问题需要在其他更高的项目中重复，比如说，如果修复程序会破坏API，或者它是一个关键问题，应该警告库的任何用户），但是我想保留原文，因为在将其修复到模块中并关闭模块之后问题是，将固定模块集成到产品中需要更多时间。
我找到了允许在转换时使用后期函数的插件，例如“CustomWare JIRA Utilities”，因此应该用于自动克隆，链接和更新，尽管我不是100％肯定。
但缺少的是管理不同版本的产品和模块之间的依赖关系的好方法（即，产品A的版本XY使用库B的版本IJ），因为版本化的组件是JIRA所做的另一件事不行。
有更好的想法吗？
答案 0 :(得分：1)
我会将可重用组件的处理方式与处理它们（例如DLL）的方式相同，作为Jira中的单独项目。
针对受影响的模块版本跟踪您的问题。如果发现项目是不同的部分，您可以随时在项目之间移动问题。
这无助于维护跨项目映射（即系统A v1.3需要组件B v2.7），但它变得非常简单，可以转储到Wiki中。
答案 1 :(得分：0)
另一种方法是创建自己的多选自定义字段，使其在多个JIRA项目中有效，并使用它而不是系统组件字段。您将失去自动分配问题的能力，但却能够使用在多个项目中有效的“组件”。
〜马特
答案 2 :(得分：0)
OnTime使用基于树的结构进行项目，允许您打开过滤器以查看后代，就像它们在当前分支上一样。我不知道这对你有多大帮助。