4.3　缺陷管理系统与版本管理系统的关联

随着缺陷管理系统的导入，任务的管理变得简单，项目也开始顺利运转，接着应该着手的就是和版本管理系统的关联了。关联问题票和代码的修改能够使问题或 bug 的调查变得方便，由此对项目的管理也会更为得心应手。

4.3.1　通过关联实现的功能

通过关联两个系统能够实现如下这些功能。

●…… 从提交链接到问题票

利用这个功能能够从代码的修改追溯到原本的问题票。特别是在以开发者的角度来调查代码的修改时，该功能非常方便。在缺陷管理系统和版本管理系统密切整合的系统中可以使用该功能，具体来说有 Trac、Redmine、Backlog、Github 等系统。

相反，缺陷管理系统使用 JIRA 或 Pivotal Tracker，版本管理系统使用另外的 Git（GitHub）的情况下，要在版本管理系统的提交记录中添加缺陷管理系统的问题票的链接就比较困难了，这点请注意。

●…… 从问题票链接到提交

和上述功能相反，这是一个从问题票出发，追查做出了怎样的修改的功能。主要是在从 QA 负责人、顾客或者和顾客立场相近的利益相关者的角度出发，来确认发生问题的始末、调查影响范围时，该功能非常方便。即使在缺陷管理和版本管理使用各自独立的系统的情况下，只要进行适当的配置，多数情况下还是能够使用该功能的，所以应该尽量地加以利用。

●…… 提交的同时修改问题票的状态

这是一个在向版本管理系统进行提交的同时修改相关联的问题票的状态的功能。该功能能够使开发人员的提交作业和项目的工作流程相关联，帮助加快开发速度。

4.3.2　关联的配置方法

几乎所有的缺陷管理系统都具备和版本管理系统相关联的功能，配置的方法也基本相同。实际进行配置时，只要参考文档或相关书籍等资料，应该都能够顺利地进行。

这里，我们以使用 Git 版本管理系统为前提 28 ，就上述介绍的缺陷管理系统之中的一些主要产品的配置方法进行简单的说明。

28 关于 Subversion 和缺陷管理系统的关联方法，请参考文档、书籍或网络资料等。

4.3.3　GitHub

●…… GitHub 的 issue

关联 GitHub 自带的 issue 功能和代码修改是非常简单的，只需在提交记录中像下面这样加入 issue 的号码即可。

这样从提交到 21 号 issue 的链接就创建起来了。GitHub 还会在 21 号的 issue 中添加相应的提交记录的链接，并把其状态修改为 close。可以说必要的功能是一应俱全的。

像这样，GitHub 较好地具备了关联缺陷管理系统和版本管理系统的功能。就这样运用 GitHub 应该也没有什么太大的问题，只是很多开发团队已经在使用其他缺陷管理系统。另外，因为需要使用 GitHub 所不具备的报表生成功能而另行选用其他缺陷管理系统的团队也不在少数。

在这样的情况下，可以将 GitHub 彻底地作为版本管理系统来使用，使用其他的产品作为缺陷管理系统。GitHub 同样提供这样的功能。

●…… Service Hooks

GitHub 为每个代码库提供了和其他服务相关联的机制（图 4.10），该机制称为 Service Hooks。它能够在向 Git Push 代码时通过 Hook（挂钩）和其他服务进行信息交互。在各代码库的菜单中依次选择 Settings>Webhooks&Services>Configure services，就可以进行确认。配置时需要该代码库的 Admin 权限，这点请注意。

图 4.10　Service Hooks

如图 4.10，GitHub 提供了世界上几乎所有系统的 Hook。从中找出自己所使用的缺陷管理系统的 Hook 并进行配置，这样就实现了 GitHub 和缺陷管理系统的关联。

而万一没有提供相应的 Hook 的话，则有以下两个办法。

其一就是配置 Webhooks（图 4.11）。这是一种向设定的 URL 发送固定格式的 POST 请求的通用做法。在和公司内部独自开发的系统关联时就能发挥作用。顺便说一下，GitHub 发送请求的服务器的 IP 地址是公开的 29 ，所以在和公司内部系统进行关联时还可以使用 IP 过滤，消除安全方面的隐患。

29 http://developer.github.com/v3/meta/

图 4.11　Webhooks

其二就是自行开发 Service Hooks。GitHub 的 Service Hooks 是作为 OSS 公开在 GitHub 上的 30 。只要按照说明开发 Hook 并公开，全世界的工程师就都能使用该 Service Hook。

30 https://github.com/github/github-services

●…… GitHub 和 Pivotal Tracker 的关联

Pivotal Tracker 是 GitHub 的 Service Hooks 中提供 Hook 的服务之一。

只需要配置 Pivotal Tracker 所发行的 Token 和对象 Branch（分支）即可运行（图 4.12）。Branch 处空白的话，每次 Push 修改时都会监听所有分支，并在相应的 PivotalTracker 的问题票中添加链接。EndPoint 通常可以为空，Pivotal Tracker 的话只有在使用 custom domain 的情况下才需要配置 EndPoint。

图 4.12　GitHub 的 Service Hook（Pivotal Trakcer）

配置完成后，在提交时添加如下提交记录，则对应的问题票（这里是问题票 ID123456）和修改的内容就关联起来了。

用“[]”将票号（#+ 号码）围起来。这时如果该问题票的状态是“not started”的话，则状态会自动更新为“started”。

若要在关联修改的同时把问题票的状态设置为“finished”，可以像下面这样添加提交记录。

其他的格式可以参考 Pivotal Tracker 的帮助 31 。成功关联 Pivotal Tracker 和 GitHub 的话，如图 4.13 所示，问题票和代码修改之间的关联就创建起来了。

31 https://www.pivotaltracker.com/help/api?version=v3#scm_post_commit_message_syntax

图 4.13　创建问题票和代码修改之间的关联

●…… GitHub 和 JIRA 的关联

JIRA 也和 Pivotal Tracker 一样，GitHub 在 Service Hooks 中提供了相应的 Hook。只需输入必要的信息，就能和 GitHub 进行关联。

提交时输入如下提交记录即可。JIRA 的情况下，C00LAPP-123456 这部分是对应的问题票号。

使用 Service Hooks 的关联是以代码库为单位进行配置的，所以每增加 1 个代码库都必须对其进行配置。如果觉得麻烦的话可以用一些灵活的方法来应对，例如用 JIRA DVCS Connector Plugin32 对 GitHub Organization 进行统一配置等。各位可以试着使用这些功能。

32 https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-bitbucket-connector-plugin

4.3.4　Trac/Redmine

在 Subversion 还是主流的版本管理系统的时代，比较多见的是使用 Trac 或者 Redmine 对问题票和代码进行管理。那时一般是自行在服务器上创建 Subversion 的代码库，将 Trac 或 Redmine 设置为代码库的浏览器，再配置相互之间的关联。

但自从 GitHub 出现后，Git 的简洁以及 GitHub 的 Pull Request 的便利开始逐渐为人所知并得到普及，现在已经没有太大的必要特意自行构建 Git 仓库，并使用 Trac 或 Redmine 作为代码库的浏览器了。坦率地说，如今使用 GitHub 的费用也已经比较合理了。完全可以用 GitHub 作为代码库浏览器，而将 Trac 或 Redmine 作为纯粹的缺陷管理系统来使用。

GitHub 的 Service Hooks 中已经提供了 Trac 和 Redmine 的服务，请加以有效使用。

4.3.5　Backlog

Backlog 原本是作为提供类似于 Trac 和 Redmine 的功能的 SaaS 开始开发的。其特征是支持 Subversion，和 Trac 和 Redmine 一样可以作为代码库浏览器来使用，问题票和代码修改的关联容易。

Backlog 最近也开始支持 Git 了。在线托管 Git 的 SaaS 除了 GitHub 之外并不多，日本国内比较有名的也就只有 Backlog 了。使用 Git 作为版本管理系统的话，GitHub 在大多数情况下都是最好的选择。但考虑到项目的差异以及预算，Backlog 也是非常有竞争力的选项。

并且，GitHub 的 Service Hooks 中公开有 Backlog 服务，所以可以采用这样的方法：将 Backlog 作为纯粹的缺陷管理系统来使用，版本管理系统则使用 GitHub。

●…… Backlog 和 Git 的关联

关联 Backlog 和 Git 的配置比较简单。可以分别为每一个项目进行配置（图 4.14）。只需要在各项目的“项目设置 >Git> 设置”中选中“连接课题和关键字”即可。

图 4.14　关联 Backlog 和 Git 的配置

配置完成后，在提交记录中输入如下内容即可进行关联。

如图 4.15 所示，问题票和代码修改关联起来了。并且，从代码到问题票的链接也如图 4.16 这样创建起来了。

图 4.15　关联问题票和代码修改

图 4.16　从代码到问题票的链接

●…… Backlog和 GitHub 的关联

Backlog 公开在 GitHub 的 Service Hooks 中，所以和 GitHub 的关联也是非常容易的（图 4.17）。

图 4.17　GitHub 的 Service Hook（Backlog）

4.3.6　Git 自带的 Hook 的使用方法

使用像 GitHub 和 Backlog 这样的系统，缺陷管理系统和版本管理系统之间的关联的确比较容易。但因为无法定制 Git 自身，所以自由度和灵活度方面还是受到了限制。之前提到的系统大部分只公开了 Git 的服务器端 Hook 中的 Post-receive Hook，并没有公开所有的 Hook。

自己搭建 Git 服务器的话，就能够使用 Git 所提供的所有 Hook。在 Git 的代码库的 .git/hooks/ 目录下，Git 提供了许多分别运行在服务器端以及客户端的 Hook。该目录下存放有默认文件名为 *.sample 的示例脚本，以此文件为样本进行开发，可以写出各种各样的 Hook33 。

33 详细内容请参考 Git 的文档。http://git-scm.com/book/zh/自定义-Git-Git挂钩 。