我使用cruisecontrol.rb为CI和FogBugz进行错误跟踪，但回答越一般，效果越好。如何将我的持续集成系统与我的错误跟踪系统集成？
首先是技术问题：是否有FogBugz的API？有没有好的教程，或更好的，预先编写的代码？
其次是程序问题：在构建中断时，CI究竟应该将错误跟踪器置于什么位置？也许：
标题：“＃{last committer}破坏了构建！”
身体：“＃{错误痕迹}”
我想这预示了这个问题的答案：我竟然把CI闯入我的bug跟踪？
我与之合作的所有CI设置都会发送一封电子邮件（列表），但如果您确实需要 - 特别是如果您的团队使用FogBugz作为待办事项系统 - 您可以在FogBugz 6中打开一个案例。 It has an API，让你打开案件。对于这个问题，您可以将其配置为将电子邮件发送至您的FogBugz的电子邮件提交地址，但该API可能会让您做更多工作，例如将案例分配给最后一位提交者。
Brian的答案向我暗示，如果您的CI在发现具有案例编号的提交失败时，您甚至可能会重新打开现有案例。就像为每一件小事情编写案例领域一样，CI自动化可能会“太聪明”，弄错了，只是很烦人。打开一个新的案例可能会很多。
谢谢：这让我想知道是否应该尝试将我们的Chimps设置与我们的FogBugz整合！
CC带有一个实用程序，在构建失败时提醒您，它可能不值得在FogBugz中记录失败的构建 - 您不需要跟踪立即解决的问题（因为大多数构建破坏）
换个角度来看，FogBugz很容易配置，因此它可以显示正确的变化（FogBugz显示修复问题的checkin）。
在我的公司，我们最近采用了（商业）Atlassian堆栈 - 包括用于问题跟踪的JIRA和用于构建的Bamboo。很像微软的世界（我猜 - 我们是一家Java商店），如果你从一个供应商那里得到所有的产品，你就会得到紧密集成的奖励。
有关他们如何完成互操作性的示例，请查看他们的interoperability page。
足够先令。一般来说，我可以总结他们的一般方法：
具体到你的第二个问题：
您的CI并不没有把任何东西到你的bug跟踪系统。 Bamboo不会将任何东西放入JIRA中。相反，Atlassian的人为JIRA提供了一个插件，它将向Bamboo进行远程API调用，问一个问题：“竹子，我构建的是什么（JIRA问题）？”。这可能是最好的解释，screenshot。