我使用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。