我将cruisecontrol.rb用于CI，使用FogBugz进行错误跟踪，但是答案越笼统，就越好。

首先是技术问题：FogBugz是否有API？是否有好的教程，或者更好的是，预先编写的代码？

第二个是程序问题：在构建中断时，CI到底应该在Bug跟踪器中放置什么？可能：

标题："＃{last committer}破坏了构建！"

正文："＃{错误痕迹}"

我想这以对这个问题的答案为前提：我是否应该在错误跟踪中加入CI中断？

解决方案

回答

CC附带有一个实用程序，该实用程序会在构建失败时向我们发出警告，它可能不值得在FogBugz中记录失败的构建，因为我们不需要跟踪立即解决的问题(因为大多数损坏的构建都会如此)

反之(FogBugz显示可解决该问题的签入)，我们需要易于配置的基于Web的存储库浏览器FogBugz，以便显示正确的更改。

回答

在我公司，我们最近采用了(商业)Atlassian堆栈，包括用于问题跟踪的JIRA和用于构建的Bamboo。就像微软世界(我猜我们是一家Java商店)一样，如果我们从单个供应商处获得所有产品，则可以获得紧密集成的好处。

有关他们如何实现互操作性的示例，请查看其互操作性页面。

先令足够。一般来说，我可以将它们的一般方法总结为：

• 在错误跟踪器中创建问题(例如：PROJ-123的问题密钥)。
• 提交代码时，请在提交注释中添加" PROJ-123"，以指示此代码更改可修复的错误。
• 当CI服务器签出代码时，请扫描差异的提交注释。记录与问题密钥的正则表达式匹配的所有字符串。
• 构建完成后，生成有关发现了哪些问题密钥的报告。

专门针对第二个问题：

CI不必在Bug跟踪器中添加任何内容。 Bamboo不将任何东西放入JIRA。相反，Atlassian的人们为JIRA提供了一个插件，该插件将对Bamboo进行远程api调用，并询问" Bamboo，我与JIRA相关的是什么版本？"。最好用截图来解释。

回答

我曾经使用过的所有CI设置都会发送电子邮件(到列表)，但是如果我们确实希望，特别是如果团队将FogBugz用作待办事项系统，则可以在FogBugz 6中打开一个案例。案件。为此，我们可以将其配置为将电子邮件发送到FogBugz的电子邮件提交地址，但是API可以让我们做更多的事情，例如将案例分配给最后的提交者。

Brian的答案向我暗示，如果CI在提交的案例中发现案例编号失败，那么我们甚至可以重新打开现有案例。就像为每个小事情整理一个case字段一样，CI自动化有时会"太聪明"，弄错了，而且很烦人。开一个新案子可能就足够了。

谢谢：这让我想知道我是否应该将我们的黑猩猩设置与我们的FogBugz集成起来！