4

我们正在将我们的错误跟踪从一个非常旧版本的跟踪迁移到 Bugzilla，而我的 Advil 快用完了。

我们有一个已经存在很长时间的遗留应用程序。事实上，我们的版本管理已经经历了几次迭代，它在野外产生了很多不同的版本。更糟糕的是，由于合同限制，并不总是可以将客户端升级到最新和最好的，因此我们必须在他们当前拥有的版本上进行分支、修复、测试和发布，从而产生另一个版本号。

最终结果是版本组合框长得可笑。最后，出于各种原因，我们要跟踪三个不同的版本信息：发现错误的版本（版本）、我们计划修复的版本（里程碑）以及最终修复的版本（接受建议）。这实际上是我的问题......这实际上可以是多个数字，我们为其中一些客户进行了追溯修复（这种情况经常发生）。

这就是我需要你们集体智慧的地方：

您如何在 Bugzilla 中跟踪这些版本（找到的、计划的和多个已修复的）？

链接版本和错误跟踪的最佳实践是什么？

答案

似乎为每个版本克隆 bug 是一种很好的跟踪方式，因此目标版本总是在里程碑和修复版本中被跟踪，而有 bug 的版本总是原生版本。

此外，让每个克隆都阻止原始错误，使其成为将历史追溯到原始提交的好方法。

虽然我已经接受了答案，但我仍然欢迎您的意见。

4

4 回答 4

3

通常，如果我们需要修复多个发布版本（通常是源代码存储库中的分支）中的某些内容，则会为每个分支克隆错误，以便可以单独跟踪所有提交和发布状态。我认为我们唯一不这样做的时候是更改与代码库本身没有直接关系，并且不能简单地通过更新我们的库来修复。

至于一般的版本跟踪，这让我觉得这是一种合理的做事方式，因为我们通常只需要随时支持 2-3 个主要版本（加上主干）。如果您有多个不相交的版本需要支持，例如客户特定的部署，那么事情将更难跟踪。（可以说这通常会引起头痛，最好将事物统一到更中心的版本主题中）。

于 2009-01-13T09:48:52.563 回答
3

我使用 Bugzilla 不仅可以跟踪错误，还可以跟踪新功能、增强功能和模糊的想法。对于每个计划和发布的版本，我都有一个 Tracking Bug（我在最初的 Mozilla bugzilla 上看到的，并且发现它很有用）。

因此，如果您有错误报告，请输入带有报告的版本号的错误。创建额外的错误（您计划修复它的每个版本一个），这些错误都依赖于（阻止）原始错误并阻止特定于版本的跟踪错误。

如果阻止原始错误的所有错误都已关闭/验证（无论您的 QA 实施什么），您也可以关闭原始错误。

于 2009-01-13T10:22:28.957 回答
3

我在 TFS 中寻找类似的功能，在进行一些调查时，我发现在 Bugzilla 中有一个管理“目击”的增强请求：“Bug 55970 - (bz-branch) Bugzilla 需要更好地处理分支（实现目击事件）”： https ://bugzilla.mozilla.org/show_bug.cgi?id=55970

还有一个提议的设计： https ://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912

有关信息，我们将在 TFS 2010 中实现类似的东西，使用“Bug Parent”或“Bug Master”来保存有关错误本身的信息（重现步骤、严重性、技术信息、受影响的组件......），即可以有类型为“Bug Child”或“Sighting”的子级，它将保存特定于给定分支的信息（目标里程碑、优先级、该分支的特定信息......）。

于 2012-05-29T12:29:23.187 回答
2

我们正在使用jira，但仍然有这个问题。我认为这是一个需求问题以及如何使用版本而不是任何一种工具。

谁使用版本以及他们如何使用它们？
版本与项目计划中的里程碑有何关联？

我们使用 4 decet 版本（major.minor.patch.buildNO）。buildNo 是构建时的 SVN 头版本号。每个版本都存储在 JIRA 中，问题有一个影响版本和固定版本字段，这是一个多选。

不久之后，我们有很多版本。Jira 确实允许我们以两种方式控制列表 1. 存档版本（从选择列表中显示为灰色） 2. 合并版本（将多个版本一起滚动到新版本中 - 不可撤消）

我们使用了存档，但由于缺少撤消而避免了合并。所以我们仍然有许多版本的列表。

我敢肯定，您可以通过一些脚本和时间在 Bugzilla 中完成合并操作，问题是：什么时候可以将几个旧版本合并在一起？

如果我已经发布，我是否需要知道我在开始和发布之间有 17 个构建？我是否需要了解在 build 1 中发现的 bug，在 2 中修复，在 7 中再次发现，在 9 中再次修复？还是在 1.0.0 版中找到在 1.0.1 版中修复是否足够好？

我将在今天晚些时候就这个话题提出一个大问题，但我已经知道基本答案： -取决于您的团队想要如何跟踪事情。

实施很有趣，但这一切都归结为需求、目标和从用户体验到解决方案的工作。当人们不一定知道要如何使用他们想要使用的形式并不完全存在的东西时，这很粗糙。

于 2009-05-06T16:48:39.647 回答