持续集成:如何将构建与需求/任务/错误联系起来?

Wim*_*dse 8 continuous-integration task traceability

您如何回答管理人员,测试人员和团队中其他人员的以下问题:

在什么版本的bug#829修复?我们当前的测试版本中完成了哪些任务?

简而言之,您如何实现从报告到部署报告的需求,任务和错误的可追溯性?您使用了哪些流程,工具和技术来实现这一目标?

Eoi*_*ell 3

我们在公司中使用TRACSVN ,并对开发/暂存和稳定环境执行每日滚动构建,并定期计划部署(每月一次......左右)到生产环境。

当报告错误时,它会被输入 TRAC 并给出票证编号(例如#1001)

当错误修复后,代码将通过 SVN 签入注释中的票号(#1001)重新签入 SVN。

开发人员记下 SVN 变更集编号(例如 [5000])并打开 TRAC Web UI。关闭票证时,他们将变更集编号放入票证的注释中。

这样,SVN 签入会引用票证...票证会引用 SVN 签入。

然后,我们的日常构建将针对 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
Run Code Online (Sandbox Code Playgroud)

这样,测试人员在检查测试修复时就可以通过票证注释中的变更集知道他们正在查看的构建是否包含修复。