JIRA：如何在项目之间共享模块？
我的公司两年前开始使用 JIRA 进行问题跟踪，从那以后我们一直在努力优化它的工作流程。主要问题是我们有许多在不同产品之间共享的模块和库，而 JIRA 具有项目的“筒仓”视图。基本上，JIRA 非常适合从“客户项目”的角度跟踪问题，但我开始认为它对于“后端开发”的角度越来越无用。
JIRA 的组件不足以满足我的需求，因为模块或库的开发人员无法将其模块的不同项目中出现的问题关联起来，并将它们分配给不同的版本。我需要的是项目的层次结构，其中较高（产品）级别项目中的组件与较低（模块）级别的另一个项目相关。
Atlassian 似乎不愿意（无法？）向 JIRA 添加这样的功能，尽管许多相关问题可以追溯到九年前。不过，目前对我们来说转向另一个具有此功能（如果存在）的问题跟踪软件是不可行的。
从Atlassian的JIRA系统中相关问题的回复数量来看，我们不可能是唯一遇到这个问题的公司，所以我想知道其他人是如何解决这个问题的。
我当前的计划是在产品项目中使用组件，并在相关模块/库项目中自动创建和链接组件问题的克隆。克隆不是最佳的，因为它们与原始版本的联系并不像我希望的那样紧密，并且它们使系统中的问题数量增加了一倍（或者更多，如果模块项目中的问题需要在其他更高的项目中重复） ，比如说，如果修复会破坏 API，或者如果这是一个应该警告库的任何用户的关键问题），但我想保留原始版本，因为在模块中修复它并关闭模块之后问题，集成固定模块需要更多时间到产品中。
我找到了允许转换后功能的插件，例如“CustomWare JIRA Utilities”，因此应该适用于自动克隆、链接和更新，尽管我不是 100% 确定。
然而，缺少的是管理不同版本的产品和模块之间的依赖关系的好方法（即产品 A 的 XY 版本使用库 B 的 IJ 版本），因为版本化组件是 JIRA 不做的另一件事。
还有更好的想法吗？
My company started using JIRA for issue tracking two years ago, and we have struggled with optimizing the workflow for it since. The main problem is that we have a number of modules and libraries that are shared between different products, whereas JIRA has a "silo" view of projects. Basically, JIRA is fine for tracking issues from a "customer project" point of view, but I started to see it as more and more useless for a "back-end development" point of view.
JIRA's components are not good enough for my needs, since the developer of the module or library cannot correlate the issues appearing in different projects for her module and assign them to different versions of it. What I need is a hierarchy of projects, where a component in a higher (product) level project relates to another project at a lower (module) level.
Atlassian seems to be unwilling (unable?) to add such a feature to JIRA, despite numerous related issues dating back up to nine years. Moving to another issue tracking software that has this feature (if there exists any) is not feasible for us at the moment, though.
Judging from the number of replies on the related issues in Atlassian's JIRA system, we can't be the only company with this problem, so I would like to know what other people are doing to get around it.
My current plan is to use components for the product projects, and automatically create and link clones of component issues in the relevant module/library project. Clones are sub-optimal, since they are not as strongly linked to the original as I would like, and they double the number of issues in the system (or more, if the issue in the module project needs to be duplicated in other higher projects, say, if the fix would break the API or if it was a critical issue that any user of the library should be warned about), but I'd like to keep the original, since after fixing it in the module and closing the module issue, there'd be more time needed for integrating the fixed module into the product.
I have found plugins that allow post-functions on transitions, e.g. "CustomWare JIRA Utilities", so that should work for automated cloning, linking, and updating, although I am not 100% sure.
What is missing, though, is a good way to manage the dependencies between the different versions of products and modules (i.e., version X.Y of product A uses version I.J of library B), since versioned components are another thing that JIRA doesn't do.
Any better ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会像对待分发一样对待可重用组件（例如 DLL），将其视为 Jira 中的单独项目。
针对受影响的模块版本跟踪您的问题。如果发现问题是不同的部分，您始终可以在项目之间转移问题。
这无助于维护跨项目映射（即系统 A v1.3 需要组件 B v2.7），但它变得足够简单，可以转储到 Wiki 中。
I would treat reusable components the same way they're treated for distribution (e.g. DLLs), as separate projects in Jira.
Track your issues against the affected version of the module. You can always move an issue between projects if it's discovered to be a different part.
This won't help maintain cross project mapping (I.e. System A v1.3 requires Component B v2.7) but it becomes simple enough to dump in a Wiki.
另一种方法是创建您自己的多选自定义字段，使其在多个 JIRA 项目中有效，并使用它代替系统组件字段。您将失去自动分配问题的能力，但获得使用在多个项目中有效的“组件”的能力。
〜马特
Another approach is to create your own multiselect custom field, make it valid across multiple JIRA projects and use that instead of the system components field. You would lose the ability to automatically assign issues but gain the ability to use "components" that are valid in more than one project.
~Matt
OnTime 对项目使用基于树的结构，允许您打开过滤器来查看后代，就好像它们位于当前分支上一样。我不知道这对你有多大帮助。
OnTime uses a tree-based structure for projects, allowing you to open a filter to view descendents as if they were on the current branch. I don't know if that is much help for you.