您如何回答团队中的经理、测试人员和其他人员提出的以下问题:
在哪个版本中修复了错误 #829?在我们当前的测试版本中完成了哪些任务?
简而言之,从报告报告到部署,您如何实现需求、任务和错误的可追溯性?您正在使用哪些流程、工具和技术来实现这一目标?
您如何回答团队中的经理、测试人员和其他人员提出的以下问题:
在哪个版本中修复了错误 #829?在我们当前的测试版本中完成了哪些任务?
简而言之,从报告报告到部署,您如何实现需求、任务和错误的可追溯性?您正在使用哪些流程、工具和技术来实现这一目标?
我们在公司中使用带有SVN的TRAC并执行每日滚动构建到 DEV / STAGING 和 STABLE 环境,并定期安排部署(每月一次...... ish)到生产环境。
当一个错误被报告时,它被输入到 TRAC 并给出一个门票编号(例如 #1001)
修复错误后,代码将使用 SVN Checkin 注释中的票号 (#1001) 重新签入 SVN。
开发人员记下 SVN Changeset 编号(例如 [5000])并打开 TRAC web ui。关闭工单时,他们将变更集编号放在工单的注释中。
这样,SVN checkin 引用票证...并且票证引用 SVN Checkin。
然后,我们的日常构建针对 SVN 变更集执行(例如,今天的构建是变更集 [5050] 的所有内容),并在我们的部署通知中对此进行了说明。
Deployed On | Environment | Changeset
--------------+-------------------------+--------------------------
10-01-2008 | DEV | 5100
10-01-2008 | STAGING | 5080
10-01-2008 | STABLE | 5050
01-01-2008 | PRODUCTION | 5000
这样,测试人员在检查修复以进行测试时,可以通过票证评论中的变更集了解他们正在查看的构建是否包含修复。
我们将 TFS 与 JetBrains 的 TeamCity 结合用于 CI。
将签入与任务关联时,我们的自定义签入策略会将关联的任务和错误及其 ID 和标题添加到签入注释中。
然后使用这些注释生成发行说明,这些说明会为每个构建自动生成。
我们使用已修复的缺陷编号或已实施的增强编号标记源代码控制签入。
通过检索两个构建之间的签入日志,您可以确定已实施或修复的内容。
我们使用名为 Beanstalk ( http://www.beanstalkapp.com/ ) 的托管 SVN 服务,它允许您轻松地与许多 Bug/Feature 管理系统配合使用。在我们的例子中,我们使用 Fog Creek 的 FogBugz 来达到这个目的。SVN/Beanstalk 允许您在签入构建时做笔记,这反过来会影响一个或多个FogBugz案例的状态。
在客户端,我们使用 Tortoise SVN 和 Visual SVN 来管理本地客户端和 Beanstalk SVN 服务器的交互(Tortoise 提供实际服务,Visual SVN 提供 Tortoise SVN 和 MS Visual Studio 之间的集成)。
我强烈推荐这两种服务和 Tortoise/Visual SVN 客户端。
我们正在使用具有内置颠覆集成的 Fogbugz。基本上有一个 Fogbugz 插件,可以在后台检查 SVN 签入。因此,如果您在签到时提供 Fogbugz-case id,它会自动与此签到相关联。
据我所知,您不需要任何特殊应用程序(例如 Beanstalk)。
反过来就有点棘手了。在我们公司有一个约定,对于每个(未来或过去)构建,Fogbugz 中都有一个“发布”。如果您修复了错误或实现了某个功能,您可以将案例分配给正确的版本。
然后很容易获得构建 X 的所有实现功能的列表。