问题标签 [bug-tracking]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
svn - VCS 和单一开发人员“团队”
我是一名开发人员,正在为我的公司开发一个项目。我使用 subversion 和 Trac(用于错误跟踪和与管理类型的通信)。我有一个登台服务器和一个生产服务器。今天我检查了一些代码,发现我的基于 FSFS 的 svn (v1.4) 存储库已不可挽回地损坏。虽然这很糟糕,但它让我有机会将我的 VCS/staging 系统迁移到更现代的发行版(目前在一个 2 年前的系统上)。(就回购而言,我确实有一个未损坏的当前代码版本,所以当我丢失所有开发历史和评论时,我不会丢失任何代码。唷。)
目前我在 Ubuntu 上开发,生产运行 RHEL5-64。我的硬件将保持不变,一个 32 位 x86 单核系统。
我熟悉 SVN 及其结构,但我对 FSFS 损坏问题感到有些恼火。我对 git 了解不多,只是它很受欢迎。我目前使用 Trac 来管理问题,我真的很喜欢它与 svn 的集成。似乎有插件可以支持 Git,但我不确定该开发的成熟度。
我目前正在考虑构建以下内容:
- Ubuntu 8.10 桌面(然后添加 apache2 和其他软件包……上次我尝试将 GUI 添加到服务器版本时,我差点把头发拉出来)
- SVN(因为我很熟悉它,而且 Git 对于一个人的团队来说似乎有点矫枉过正)
- Trac(因为我熟悉它并且它适用于 SVN)。
我想对我的“新”vcs 系统提出一些建议和想法。我有理由转向 Git 吗?有什么比 Trac“更好”的吗?
process - 错误跟踪和帮助工单应该如何集成?
我对错误跟踪系统(例如 FogBugz)有一点经验,其中帮助票是(或可能是)错误,并且我在内部使用完全独立于帮助中心系统的错误跟踪系统有一些经验。
我的问题是,在一家拥有现有(本土)帮助中心系统且无法替换它的公司中,应该如何将错误跟踪系统(可能是 Mantis)集成到流程中?
现在,为问题、疑问等提供帮助票证,并将它们分配给适当的人(PC 技术、帮助台工作人员,或者如果这是他们无法在帮助台解决的应用程序问题,则分配给开发人员)。用户可以在帮助工单中提出对应用程序进行小的修改或修复的请求,分配给它的开发人员将在某个时候进行更改,将他们的时间应用于该工单,然后在工单投入生产时关闭工单.
我们目前没有错误跟踪系统,所以我正在寻找最好的集成方式。如果它是错误(或问题或功能请求),我们是否应该只获取帮助票并将其放入错误跟踪系统,然后如果不是紧急修复则关闭票证?我们可能不想将错误跟踪系统暴露给其他任何人,因为他们不知道在帮助中心系统中放置什么以及在错误跟踪器中放置什么......对吗?
有什么想法吗?建议?尖端?建议?待办事项?不是待办事项?ETC...
git - Git 和 Trac(或类似的)
过去,我非常喜欢将Trac与托管在我自己的一些服务器上的颠覆存储库一起使用。票务和在线代码浏览一体化,非常方便。
我在一些公共项目中使用了github,但我没有钱购买额外的服务,尤其是当我已经为远程 VPS 托管付费时。
有谁知道或有任何经验使用 git 版本控制设置诸如 Trac 之类的东西?具体来说,我已经可以推送到远程服务器,但我想要一些 Web 界面,允许我(以及与我一起工作的人)在线查看代码库的提交和当前状态,而无需公开项目。我知道GitPlugin但无法成功启动并运行它。还有其他建议吗?
需要集成票务(和 wiki),但不是绝对必要的。
编辑:
在多玩了 GitPlugin 和 Trac 之后,我已经能够启动并运行它。主要问题是我需要通过在 trac.ini 中执行类似的操作来为 trac 环境显式启用插件:
bug-tracking - 满足用户报告错误的最佳方式是什么?
好吧,Bugzilla会吓跑普通最终用户的。即使是像螳螂这样的东西对于外行来说也有点吓人。
我可以实施什么方法、Web 包(首选)、界面,以使我的最终用户和客户以可理解的方式报告错误变得简单、直观且一点也不吓人?
我喜欢基于表单或点击式的想法,而不是像 Bugzilla 这样全面而令人生畏的东西所需的先验知识。
电子邮件,虽然对于普通的下注者来说是平易近人的,但似乎不太理想,因为它不会提示用户我需要尝试找出哪些信息是坏的。
到目前为止Bugs - Bug Genie似乎是普通用户面对的最不可怕的选择。我搜索但没有找到像我这样的问题。
请提出建议,想法,见解!
open-source - 开源项目中缺乏问题跟踪设施是否可能是不参与/贡献的诱因?
在决定您是否参与一个相当大的开源项目以便为其代码库做出贡献时,该项目的问题跟踪设施(即跟踪错误和功能请求)对于您做出贡献的决定有多重要?
仍然有许多非平凡的(巨大的代码库)开源项目,它们没有正式进行问题跟踪——虽然一些贡献者可能确实仍然以各种“待办事项”列表的形式私下做这件事,但我个人有发现缺乏可用性和确定使用问题跟踪是缺乏组织、结构和整体项目协调的一个相当可靠的指标。
其他人在想什么?
bug-tracking - 适用于 Windows 的最佳免费软件缺陷跟踪软件?
我正在寻找免费软件缺陷跟踪解决方案。我有使用 Mercury Quality Center 的经验,但我听说它带有五位数的价格标签。我的个人项目需要一些东西。Webforms(即 ASP.NET)将是可取的。外面有什么好东西吗?
deployment - Web 应用程序开发流程 - 版本控制、错误跟踪、单元测试、部署
描述你用来开发 Web 应用程序的过程,重点是 VC、错误跟踪、QA、单元测试、部署和其他类似的东西(减去计划/客户沟通方面的事情)。
我是这个领域的新手,所以我的粗略例子(阅读:没有使用过这个过程)无疑有点过时了,可以这么说 - 指出它的缺陷,以便我可以学习。
例如。
- 在本地 SVN 服务器上创建项目存储库。
- 为 DNS 映射创建批处理/shell 脚本。
- 签出项目,开始处理本地工作副本。
- 将功能开发为分支。
- 使用 Mantis 跟踪错误(通过其 SVN 集成链接提交错误(不知道是否存在))。
- 随手记录。
- 在分支上进行质量检查。
- 稳定时合并到主干。
- 单元测试?
- 当功能实现且稳定时提交到存储库。
- 将发布复制到存储库中的标签。例如。/项目/标签/rel-123/
- 使用 Phing 上传到登台服务器。(有人可以澄清一下登台服务器在“测试”之外的用途吗?)
- 使用 Phing 准备实时站点以进行更新、设置数据库/部署等。
bug-tracking - 漏洞维护系统
我最近花了很多时间阅读有关调试的信息。不断引用的方面之一不仅仅是错误跟踪系统,而是错误解决过程。我读到有人写下对问题的看法(有效或无效),测试将确定给定的修复方法是否有效,等等。
所以我在想,“嘿,这是个好主意”
我现在使用 Mantis,它似乎没有这种能力(没有滥用它的领域)。Mantis 非常适合作为错误记录器。但我认为,我正在寻找界面更复杂的东西。
例子
假设我的错误是“裤子掉了”。然后我想将此信息记录为...
“裤子掉了,2009年2月32日25点61分,我走进房间,裤子掉了!”
开发商一...
假设1:裤子太大。
测试一:系上腰带。
可能的解决方案 1:购买皮带。
结果 = ?? 结果 ???
测试2:穿上你妹妹的裤子。
可能的解决方案 2:在她上学的时候偷走她的房间并拿走她所有的裤子!
结果 = ??,日期/时间 = ???
开发商 2...
假设 2:你的裤子上有洞。
测试1:照亮他们。
可能的解决方案:购买新裤子。
结果 = ???,日期/时间 = ???
现在,这是一个愚蠢的例子。但我认为拥有作为软件工具会很棒。是否存在,如果存在,它叫什么?
project-management - 将生产力提高到每人/天 1 个错误修正
我是一名高级软件工程师,几个月前我被要求帮助协调错误更正。项目经理(非技术人员)给了我一个目标,将生产力提高到每人/天 1 个错误修正。这是一个真正的挑战,我想知道其他开发人员/经理可能会采取哪些措施来提高错误纠正率。
在这种情况下起作用的一些因素:
- 团队地理分布(欧洲、亚洲、澳大利亚),每个区域有 10-20 名开发人员
- 大型代码库,我不太熟悉,因为我在公司只工作了 9 个月
- 只有最缺乏经验的开发人员被分配到错误更正,最有能力的开发人员正在致力于改进
- 我们遵循敏捷,所以我们使用源代码控制、持续集成、错误数据库,项目有新工作的时间表和规范,我们有测试人员并进行可用性测试
- 我们的代码依赖于许多内部和第三方组件/库
- 项目经理有一些旧的错误纠正指标,显示每人/天纠正 0.7 个错误。我担心的是,这是基于一组经验丰富的开发人员开发原型,纠正他们自己编写的代码中的错误。现在我正在协调一个不熟悉代码的开发人员团队,并且错误来自验证团队。
阅读前几个答案后的更多信息:
- 我试图反对使用错误纠正的生产力指标,但这种方法并没有走得太远
- 所有错误都按优先级排序 (1-5),包括严重性 (1-5) 并标记有其他信息(例如,被另一个错误阻止、崩溃、不可重现等)
- 大多数错误在纠正时都会编写单元测试用例
- 如果可能,将特定代码区域中的错误分配给熟悉该区域的人员
- 按团队跟踪错误纠正率,并保留纠正历史记录
- 在日常站立会议中,我试图通过要求阻止问题并解决它们来让人们感动
- 所有新代码都是用单元测试编写的
- 是的,我一直在尽我最大的努力通过各种方式提高生产力指标——关闭旧的不相关的错误,创建和纠正错误,否则这些问题将在没有错误报告的情况下解决
我已经开发了直接访问 bug 数据库的 python 脚本,以自动化 bug 管理和报告创建的一些平凡方面
-