标签: bug-tracking

我使用cruisecontrol.rb进行CI和FogBugz进行错误跟踪,但答案越一般越好.

首先是技术问题:FogBugz有API吗？有没有好的教程,或者更好的预编写代码？

其次是程序问题:当构建中断时,CI究竟应该在错误跟踪器中放置什么？也许:

标题:"#{last committer}打破了构建!"

正文:"#{error traces}"

我想这预先假定了这个问题的答案:我是否应该将CI中断放入我的错误跟踪中？

我的公司是一个定制开发商店,用于许多项目,一些较大,一些较小.目前,我们通过电子邮件处理所有客户沟通.因此,我们通过电子邮件发送设计文档,将其标记并发回.然后我们推出了他们产品的测试版,他们给我们发电子邮件,提出任何错误,新功能等.等等......

当我正在努力实现一个新的错误跟踪系统(看起来它现在将是Mantis)时,我想知道如何最好地允许我们的客户与我们的开发过程接口,以便更好地跟踪功能请求和客户端提交了错误并将我们的回复传达给客户.

如果有人知道一个特别好的bug跟踪系统我会有兴趣听到这个.否则,我只是在寻找一些通用指南或良好的商业惯例,使您的公司能够有效地与客户进行交互.

更新:我的公司使用LAMPP堆栈,因为我们是一家预算有限的小商店,我们倾向于坚持使用开源和免费的工具.

大多数人是使用Team Foundation Server来处理这个还是来回发送电子邮件？

我正在尝试决定GTD应用程序.有谁知道自动与Trac同步,或者更好的是,FogBugz？

我的怀疑是没有.这让我写了一个脚本,为我做了.

• Things将数据存储在XML中,但标签的内容都是二进制的,这使得编写脚本几乎不可能.

• OmniFocus以XML格式存储数据,内容为文字文本.插件或脚本是可能的.

• 命中列表将其数据存储在sqlite3数据库中.可能比XML容易,但我还不确定.缺点是THL不支持重复性任务,这使得它作为GTD应用程序不太有用.

有没人试过这个？我错过了一个明显的应用程序？

我的团队正在寻求将我们的许多工具(SCM,错误跟踪,构建,测试)迁移到TFS.我们正在考虑分阶段移动每个系统.例如,首先移动源控件,然后移动bug /功能跟踪等等......

既然我们必须选择一个流程模板来使用源代码控制(或TFS中的任何内容),那么我们决定如何锁定？我希望避免以后再创建另一个项目(或者那不像我想的那样糟糕？).

我知道理论上可以自定义流程模板在事后配置的所有内容(对吗？),但这在实践中有多可行？

以下是我看到事情发生的方式:

1. 我们迁移源代码.我们选择微软的CMMI模板.
2. 我们创建了一个新的工作项(或签到说明),它是我们传统的错误跟踪系统的简单链接.
3. 我们工作了一段时间.
4. 我们等到(我们是一家规模不大的软件公司)的权力来制定新的TFS开发工作流程.这可能是新工作项的简单集合,也可能是配置各种内容的全新模板.
5. 我们尝试将我们的TFS项目迁移到这个新系统而不会丢失我们的历史.

我们是否会抱歉,我们不会等到所有这些决定在使用TFS之前完成？

我们经常在JIRA中报告多个版本的应用程序.但是,针对报告该问题的每个版本,不会同时提交针对这些问题的修复.这使得很难跟踪修复提交的版本,开发人员有时会忘记为版本提交修复.

有没有办法跟踪单独报告的每个版本的问题状态,但在同一问题中？除了问题的单一状态(仅在所有版本具有该状态时更新为状态,即在所有修复版本中已解决问题时将问题设置为"已解决"),我希望看到每个修订版本的不同状态.

在Atlassian页面上查看之后,我在他们的JIRA中发现了一个旧问题,它要求这样的功能.与此相关的是论坛讨论,建议对每个版本使用子任务.如果有一个插件可以在创建问题时自动创建子任务并修复版本更新,那么这将是一个很好的解决方案.有这样的插件吗？

假设我有一堆错误(工作项)都链接到一个工作项.如何确定工作项查询以获取链接到特定工作项的所有错误的列表？

当我查看特定的工作项时,我可以看到链接的错误列表,但我希望能够为此创建查询.谢谢!

我喜欢Google Project Hosting网络应用.它包括一个界面中的错误跟踪,wiki和SCM.(例如:WMD编辑器)

此解决方案是封闭源而非出售.在搜索类似的解决方案时,我发现Trac具有更粗糙的界面.

你能列出类似的解决方案？

有人问了同样的问题,但指定Git作为SCM.

寻找具有分布式团队的中型Web应用程序打开项目的问题跟踪器.我们计划在自己的服务器上运行它.新用户必须非常容易提交新问题,并且必须与其他软件很好地集成.

我们的主要要求,按重要性降序排列:

• 开源
• 能够提供非常新用户友好的错误提交
  • 提交新问题必须尽可能简单,只需要一个屏幕填写(注册后),并且几个字段可见(例如只是"摘要"和"描述"会很好)
  • 谷歌代码是我们喜欢的那种界面的一个例子; Bugzilla的Bugzilla实例(https://bugzilla.mozilla.org/enter_bug.cgi)是我们不喜欢的那种新的bug提交界面的一个例子
  • 如果默认的提交界面不是新用户友好的,只要可以使用模板/皮肤轻松修改它就没问题.除了提交新用户错误的简单视图之外,还可以使用其他字段(例如分配问题的人)来编辑错误的"高级视图".
• 有API; 或者,支持其他应用程序同时访问其数据库后端(我们希望查询和修改其他服务器上运行的其他单独软件的问题)

其他理想标准,按重要性降序排列:

• 在日常使用中不会令人沮丧
• 有一个相对较大的社区
• 与hg(mercurial)很好地集成
• 适合与外部整合:
  • 支持台/请求跟踪软件
  • 项目管理软件
  • auth系统(和/或支持OpenID登录)
• 模块化; 如果我们修改问题跟踪器,我们希望将这些改进作为一个易于其他人安装的模块发布
• 可以使用某种简单易用的问题重要性投票系统,例如Google代码上的明星; 我们打算创建或修改这样的组件以插入我们自己的外部投票系统
• 适合与SugarCRM整合

当我说"顺从"时,我的意思是我们愿意在必要时自己编写问题跟踪器的扩展代码,但问题跟踪器的架构应该适合这种扩展.

问题跟踪器还包括支持服务台或项目管理功能,只要我们可以选择集成外部软件而不是使用附带的东西.我们不需要另一个维基(我们已经有一个我们喜欢的维基).

根据谷歌搜索(见评论),最流行的开源问题跟踪器是trac,bugzilla,mantis,RT(可能还有Launchpad).我还包括Redmine,因为我从未见过最近这些问题跟踪器和Redmine之间的比较,其中某人对Redmine有些不好说,而且在民意调查中Redmine有时会击败其他人.随意建议其他人(请记住其中一个标准是"相对较大的社区").

毫无疑问,那里有多个好问题跟踪器; 上面列出的许多声称可以扩展并与其他软件集成.最有帮助的是使用不止一个人的问题跟踪器之间的直接比较.

这些在可扩展性,可整合性和可塑性方面如何相互比较？

如果您使用过多个这样的产品,您会推荐哪些产品,以及您使用过哪些产品？

哪些已经与大量的auth系统/支持台系统/等集成？

解释为什么特定流行的开源问题跟踪器(特别是上面列出的那个)不适合我们的情况的评论是非常受欢迎的; 这样可以节省我的时间.

谢谢!

我正在寻找一个选项,让JIRA将默认的一组人员应用到某个任务的观察者列表中.这有可能开箱即用吗？

特别是,每当我们发布一个版本时,我都想用子任务为它创建一个任务,并确保预定义的一组人员收到关于它们被更新/关闭的通知.

我正在为Git搜索bug跟踪器但我没有在他们的主页上找到它并且他们在GitHub上的问题跟踪器被禁用了.