JIRA如何有效管理分支机构？答案

【问题标题】：How to effectively manage branches with JIRA?JIRA如何有效管理分支机构？
【发布时间】：2009-11-20 21:22:25
【问题描述】：

我们开发的产品由跨产品（项目 1、项目 2、...）共享的核心运行时和项目/产品特定部分组成。对于这些“产品”中的每一个，我们都维护多个分支，因为不同的版本被推出到现场并需要维护，有时甚至需要向后移植。

我们还使用 JIRA 作为问题跟踪系统，但我无法找到正确的方法来为我们的产品类型/分支建模。在这种情况下似乎相关的 JIRA 元素是组件和版本：

这或多或少有效，但使用 Component 类型的分支是一种 hack，并且缺点是您不能“淘汰”组件，只能删除它们。我们选择这种方式是因为如果我们将迭代与修复版本字段中的分支混合在一起，我们将无法再查询“迭代 X 和分支 Y”（JIRA 不支持 AND 查询）。

在 JIRA 中维护分支和跟踪迭代有哪些最佳实践？

关于上下文的一些统计数据：我们谈论的是大约 4 种产品类型，每种产品类型大约需要维护 3 个主要分支。

【问题讨论】：

【解决方案1】：

我会对这个问题采取稍微不同的方法。我会为您的核心运行时和每个项目/产品特定部分设置组件，但不要使这些组件特定于分支。因此，您的 Jira 项目中可能包含以下组件：

然后，我会按版本区分不同的分支。我假设您有某种类型的版本编号系统，允许您将字段中的二进制文件绑定回特定的分支和版本。在 Jira 中为每个版本/分支设置一个版本。当您向 Jira 报告问题时，您可以选择一个或多个受影响的版本。

这个系统有几个优点：

如果问题跨越多个版本/分支，您可以识别问题中所有受影响的版本。
您可以将版本修复设置为一个或多个版本。有时，您可能只能修复主干或某个分支中的问题。也许这是一个主要问题，您必须跨分支移植修复程序。该系统让您可以灵活地查看所有内容并进行报告。

【讨论】：

我同意，理论上这是最好的方法。如果您阅读我的问题，您会发现我们实际上是这样做的，但是由于 JIRA 3 查询限制，我们使用了分支组件。现在有 2 个新的发展使这个问题可以解决： - 我们正在转移到一个新项目，我们在其中添加 2 个自定义字段：受影响的分支和修复分支，它们都从版本中获取它们的值。 - JIRA 4（现已推出）具有更高级的查询功能，即使我们只使用修复版本，也应该允许我们查询独立于分支版本的迭代。我需要回答我自己的问题

【解决方案2】：

我能想到的一种快速方法是让您的迭代名称包含分支名称（也可能包含项目名称）。然后您可以使用修复版本来表示迭代以及分支，名称如 branch1_iteration1、branch1_iteration2、branch2_iteration1 等。

这可以让您查询分支中特定迭代的问题，并且还有一个优点是您可以针对每个修复版本设置截止日期，以便您可以跟踪您是否按计划进行。

顺便说一句，我不会使用 JIRA 组件字段来表示项目（CORE、PRO1 等），而是使用单独的 JIRA 项目；这样，您将获得更好的粒度和灵活性。

【讨论】：

分支和版本结合的有趣想法，会考虑这个。关于多个项目：我们为一个产品提供了这个，这很烦人，因为一开始可能不清楚项目属于什么问题，此外您没有完整的概述。核心问题通常会影响项目特定的产品版本。
再想一想：使用命名模式，我们无法查看某个分支的所有未解决问题。真的，JIRA 应该有更好的查询。可能剩下的唯一选择是为迭代和/或分支引入自定义字段，并将所有内容建模为版本。
您仍然可以查看给定分支的所有未解决问题 - 您可以在 JIRA 过滤器中的每个字段上进行多项选择（只需按住 Control 键或 Mac 上的 Command，同时您正在做出选择）。
是的，但是我们需要为我们想要查询该组件的每一组新的开放迭代（比如接下来的 3 次左右）重做查询；这充其量是无法维护的。