4.5　回答“那个 bug 是什么时候修正的”的问题

团队开发过程中经常会从销售、顾问或者客户那里收到“那时的那个 bug，是什么时候、在哪个版本修正的？”这样的调查要求。

这时，如果已经关联了缺陷管理系统和版本管理系统的话，就有可能顺利地找出答案。

4.5.1　Pivotal Tracker 的例子

首先以 Pivotal Tracker 为例进行说明。

●…… 用记忆中残留的关键字进行检索

如果在收到这样的调查要求时能够得知问题票号，那就不必再去查找问题票了。但如果无法获得，那就只能通过调查内容中模煳的信息以及负责人模煳的记忆来找出问题票。

●…… 检索

首先使用缺陷管理系统的检索功能找出问题票（图 4.21）。这里用关键字“一并下载”进行全文检索。

图 4.21　用 Pivotal Tracker 进行关键字检索

●…… 通过问题票查找代码修改

找到的问题票中记载有指向 GitHub 修改记录的链接（图 4.22）。

图 4.22　修改记录的链接

点击链接就会跳转到 GitHub 对应的提交页面，在此可以查看提交代码的差分对比（Diff）（图 4.23）。

图 4.23　GitHub 的修改记录

这样就查到了对应的代码提交纪录。接着只要查出这个提交反映到了哪个发布版本 36 ，调查就基本可以结束了。

36 通常以标签的形式保存。

根据运用方式的不同，例如在 master 分支适当地打上发布标签并进行发布的情况下，只需要确认提交是否反映到 master 分支，就能够判断是否反映到某个版本的发布中了。

4.5.2　Backlog 的例子

再举一个 Backlog 的例子。这次版本管理系统使用 Subversion。

●…… 检索

在 Backlog 的画面上设置检索条件，对问题票进行检索（图 4.24）。这里以“程序令牌”作为关键字来检索。

图 4.24　检索问题票

确认找到的问题票的内容（图 4.25）。

图 4.25　问题票的内容

问题票中有提交记录的链接，点击链接就能确认提交的内容（图 4.26）。

图 4.26　提交记录列表

还可以通过 Diff 来比较代码的内容（图 4.27）。

图 4.27　比较代码内容

这样就通过 Backlog 将从调查到代码的修改这一整个过程串联起来了。接着也同样只需要调查清楚这些提交反映到了哪个版本的发布中就可以了。