源代码集成对Bug跟踪系统有什么好处？

Question

我正在选择用于我们项目的Bug /问题跟踪系统。 This question和this question有助于系统评估。但是，通过查看所提供的各种产品，我提出了一个问题。

某些系统将源代码控制系统集成作为一项功能进行推广。这不是我以前用过的东西，看着各种工具的网站，我找不到关于这种集成提供的精确内容的任何细节。它不仅仅是通过我用于引发错误的同一个Web界面浏览我的存储库吗？

这样的整合有什么好处？它将如何节省我的时间或使我们的产品更好？

Answer 1

Jira和FishEye（SCM浏览器）一起，如果您提交带有包含Jira问题密钥的日志消息的变更集，例如“PROJ-123”，请插入一个链接相应的Jira问题，Jira将在PROJ-123中显示指向变更集的链接，提及该问题。

Jira还可以与Hudson集成，以便在执行包含修复（即变更集）的构建时，该提交的日志消息中提到的Jira问题将获得有关构建状态的注释

由于问题跟踪器用于跟踪源代码的问题，因此可以在集成的问题/源代码管理系统中想象出一大堆功能。

Answer 2

我使用Visual Studio Team Foundation Server完成了这项工作，它不仅集成了源代码控制，还集成了数据仓库。这使得它可以跟踪，例如，哪些错误是由哪些代码引起的，显示哪些代码需要更多的QA。 2010版的即将推出的功能更具吸引力。

Answer 3

主要优点是您可以针对特定的源代码修订提出错误。这只是在发现错误时帮助识别代码库的状态。我认为这个领域的热门产品是Trac，它与SVN集成。

Answer 4

嗯，我想说这里有一个很重要的原因，那就是你可以采用任务/问题导向的方式。

我的意思是：

• 您执行的所有代码更改（从小型快速修复到大型新功能）都将成为Jira或Rally或Bugzilla，Trac，Mantis中的问题。你喜欢。

• 这意味着问题/任务跟踪系统必须易于使用，快速，简单等，否则开发人员会讨厌它

• 然后将每个更改与问题相关联，您就完成了。您可以获得完全可追溯性（非常适合差异调试，如果您没有它，您将会错过它），更好的项目跟踪，更好的发布管理等等。

您可以将每个变更集/提交（取决于您的scm术语）链接到任务，或者，如果您的scm可以执行此操作，则为每个错误修复创建一个分支，这甚至更好。

基本上你得到的很简单：每个变化都会被记录下来，或者至少与正确的问题/任务相关联。

如果您使用分支机构，您可以推广以下内容：始终致力于稳定基线，减少主线损坏（或者如果您愿意，可以保持原始状态），确定哪些任务集成以及哪些任务保留到下一个版本，单独运行测试合并前的变化，等等。

Answer 5

Github基本上是另一种方式：所以不是包含源代码版本控制的错误/问题跟踪系统，而是插入了一些错误/问题跟踪的源代码版本控制。我不敢相信没有人在这里提到它，因为这种方式相反，这种方式更常见。

但它非常强大，你基本上可以在问题中引用git提供的所有东西：提交，分支，拉取请求。 Github甚至有一些＆＃34; automagic＆＃34;安装，合并PR与内容类似＆＃34;修复问题＃23＆＃34;，将自动关闭问题＃23。

Github也非常方便，因为现在使用的大多数开源软件也在那里托管，您也可以在自己的问题/拉取请求等中引用所有这些库。 此外，大多数围绕软件开发的典型现代商业基础架构也将与Github集成：Travis或Codeship将告诉您构建的工作方式，甚至自动部署它们，Hound或{{ 3}}会告诉您代码的外观，如果您不想使用他们的软件，Rubocop或Usersnap会将错误报告推送到您的Github问题中。

如果你将它与Github进行比较，这里的答案中提到的Trac感觉真的旧。