5.5　CI 的运用

5.5　CI 的运用

Jenkins 的配置完成后就可以实施 CI 了。这里我们来说一下 CI 运用上的小窍门以及同版本管理系统和缺陷管理系统的协作。

5.5.1　build 失败了该怎么办

开始实施 CI 后会由于某人的提交而造成 build 出错。这里所说的 build 出错是指代码无法编译（compile）、静态分析出现错误、测试失败等现象。

那么 build 失败的话应该怎么办呢？造成 build 失败的当事人应该对提交进行修改，避免 build 再度失败。而其他的团队成员应该做些什么呢？这个根据版本管理系统运用方式的不同而有所差异。

●…… Subversion 等中央集权型版本管理系统的情况

build 失败的话，从那一刻起就不得不禁止在相同代码库的相同分支上进行开发的所有成员的提交。对于全员都在同一代码库上进行开发的中央集权型版本管理系统来说，在造成失败的提交上再叠加其他人的提交的话，修改会变得更为困难。最糟糕的情况是在造成 build 失败的提交之上又叠加了其他有问题的提交，这样的事情也是存在的。

●…… Git 等分布式管理系统的情况

Git 的情况下原则上和 Subversion 一样。从 build 失败的那一刻起就要禁止在相同代码库的相同分支上进行开发的所有成员的提交，这是比较简便的运用方法。采用第 3 章中介绍的 git-flow 这样的工作流程，全员向同一个代码库进行 Push 的话，就需要禁止提交。

但是像 github-flow 这样，各个成员拥有自己的代码库，通过发送 Pull Request 进行修改的话，就没有必要禁止全员提交了。只需要在 Pull Request 被发送到中央代码库时确认该 Pull Request 和中央代码库合并后的代码是否能够通过 build 即可。这也是比较可行的方法。

专栏　造成 build 失败后的惩罚游戏

笔者所在的公司中，build 失败时会向全体成员发送邮件，并且规定从收到邮件后到 build 恢复正常为止禁止全员的提交。

为了让大家知道是谁造成了 build 失败，造成 build 失败的人要戴一顶大的礼服帽作为惩罚游戏。直到 build 修复为止，要一直戴着这顶帽子，公司内部会议也只能戴着帽子参加（图 5.c）。因为这样非常丢脸，所以大家在提交时会加倍小心。但如果做过了头就变得像追查犯人一样，导致开发人员畏首畏尾，不愿意从事具有挑战性的新功能开发。因此要保持在开玩笑 56 的程度，让团队开发顺利地推进。

图 5.c　戴大礼服帽的惩罚游戏

56 开玩笑是团队开发中的重要元素。它能够促进团队成员之间的交流，使项目顺利进展。可以采用之前提过的 XFD，或者使用 Jenkins Emotional Plugin（https://wiki.jenkins-ci.org/display/JENKINS/Emotional+Jenkins+Plugin ）这款会根据 build 结果改变 Jenkins 先生的表情的插件，都是非常有趣的。

●…… 测试后合并

本章在介绍 TravisCI 时介绍过，结合 GitHub 和 TravisCI 能够实现测试通过后再提交。其实 Jenkins 借助 GitHub pull request builder plugin 插件也可以实现同样的功能。这款插件可以实现的功能和 TravisCI 基本相同。插件的配置方法可能稍许有些复杂，具体请参考插件的帮助网站（英文）57 。这里只做简单的讲解。

57 https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin

❶ 安装插件

采用和 Git Plugin 相同的安装方法 58 安装 GitHub pull request builder plugin 插件即可。

58 请参考 5.4 节。

❷ 在 GitHub 上新建 bot 用户

插件自身为了在 Pull Request 中添加各类评论，需要 bot 用户。在 GitHub 上以适当的名字新建用户（可以使用自己喜欢的名字）。

❸ 配置 Jenkins 的系统

输入 GitHub API 的 URL 以及 GitHub 的用户名 / 密码（图 5.15）。除了用户名 / 密码之外，也可以输入 GitHub 的 Access Token（使用 Access Token 更为安全）。在 Admin list 中填写作为该插件的 Admin 的 GitHub 用户的列表。Admin 可以在 Pull Request 的评论上通过和 bot 用户的对话进行各类操作。其他的项目保留默认值即可。

图 5.15　GitHub pull request builder plugin 的配置

❹ 配置各个任务

对各个任务进行配置。首先，在 GitHub project 中填写对象 GitHub 代码库的 URL。代码管理系统的配置选择 Git，设置为 Repositories 的 Repository URL。“高级”的 refspec 栏填入 +refs/pull/:refs/remotes/origin/pr/ 。Branches to build 的 Branch Specifier 设置为 ${sha1} 。接着，在“构建触发器”中的 GitHub pull requests builder 这个选项上打钩。在 Admin list 中添加这个任务中作为 Admin 的用户信息。如果事先知道发送 Pull Request 的用户的话，可以在“高级”的 White list（白名单）中输入该用户的名称，这样配置能够简便很多。

❺ 实际发送 Pull Request

试着发送 Pull Request。对于收到的 Pull Request，中央代码库会每隔 5 分钟实行一次自动 build，build 结果将可视化地显示在 GitHub 中（图 5.16）。

图 5.16　Pull Request 的 build 结果

可以确认 Pull Request 的内容说明下方有“Determining merge status — Merged build started.(Details)”这样的信息。这是为了判断是否能够合并而开始执行 build 时输出的消息 59 。点击 Details，会迁移到相关的 Jenkins 画面（图 5.17）。

59 这时如果 build 已经成功，就会出现“Good to merge”；反之如果失败的话，则会出现“Failed”这样的消息。

图 5.17　在 Jenkins 中确认 Pull Request 的 build 结果

从图 5.17 中可以看出，25 号的 Pull Request 造成了 7 个测试失败。也就是说，这个 Pull Request 不能合并到中央代码库。

这样的运用方法能够防止将造成 build 失败的提交合并到中央代码库。因此能够避免由于某人的提交有问题而造成全员作业停止这样的事态。

❻ 添加 White list 或重新执行 build

提交 Pull Request 的用户如果还没有被添加到 Admin list 或 White list 的话，build 则不会被执行。这时 bot 用户会在 Pull Request 中添加“Can one of the admins verify this patch ？”这样的评论。对此，Admin 将下列两个回答之中的任意一个作为评论添加在 Pull Request 中，即可通过 bot 用户指示插件开始执行 build。

ok to test

实施 build。

add to whitelist

将创建 Pull Request 的用户添加到 White list 并实施 build。这样，从下次开始，由该用户创建的 Pull Request 就会被自动 build。想要再次执行已经执行过的 build 时，只需添加下列评论即可 60 。

60 这些命令语句自身都可以在图 5.15 的配置中修改。

test this please

如果觉得上述过程麻烦的话，只要在最初的任务配置阶段将用户添加到 White list 中即可。另外，正如 5.4 节的第一个专栏中所提到的那样，要想使用该插件，就需要支持 GitHub 向 Jenkins 发送请求的网络结构。添加只允许 GitHub 的 IP 地址发出请求的 IP 过滤规则，这样安全性方面就不用担心了。即使不使用 GitHub，也可以采用相同思路的运用策略。Jenkins 的作者川口耕介将这样的思路称为“验证后合并”61 。只向主分支合并经过验证的、没有问题的修改，由此来避免因某人提交造成 build 失败，进而导致全体人员作业停止的事态，团队开发的生产效率也能更上一层楼。

61 事实上 Subversion 也支持验证后合并的运用方式。

5.5.2　确保可追溯性

build 失败或发生问题时，有问题的 build 是哪次提交产生的，该提交原本是为了解决怎样的问题等，如果能够追溯上述信息，那么对于实际的运用是很有帮助的。

通过 Jenkins 和缺陷管理系统以及版本管理系统的协作，能够确保各类信息的可追溯性，实现项目的可视化（图 5.18）。

图 5.18　确保可追溯性

●…… 关联 build 和提交

阅读到这里并实施了 CI 的话，Jenkins 和版本管理系统的关联应该已经配置完成了 62 ，当然不配置的话也无法实施 CI。也就是说，只要通过 Jenkins 实施 CI，就能将 build 和提交明确地关联起来。大致的印象如图 5.19 所示。

62 请参考 5.4.4 节的内容。

图 5.19　用 Jenkins 关联 build 和提交

如图 5.19 所示，在 Jenkins 的 build 号、Git 的提交编号以及提交者这些信息之间创建起了关联。例如，可以看出 #23build 和 3 个提交有关。另外，从图 5.19 中还可以看到有代码库浏览器（本例为 GitHub）的链接，可见 build 和代码的 Diff（差分）之间的关联也创建起来了。

这样，即使 build 失败，也能够顺藤摸瓜地弄清是谁造成的、修改的内容是什么。这一功能在应对问题等时候是非常有用的。

●…… 关联缺陷管理

如果 Jenkins 已经和缺陷管理以及版本管理进行了关联的话，build 和提交，以及提交和相关问题票号之间就都创建起了相应的联系。

这次以 nulab 公司的 Backlog 产品为例进行说明。如同在第 4 章提到的，Backlog 是集缺陷管理系统和版本管理的代码库浏览器于一体的 SaaS 系统。想要关联 Jenkins 和 Backlog 的话，首先需要安装 Backlog 插件。和 Git 插件一样，请从管理插件处进行安装。安装后打开各任务的配置画面，会出现如下输入框，请输入 Backlog 工程的 URL、用户 ID（User ID）和密码（Password）（图 5.20）。同时在 Backlog 中也需要进行配置，将版本管理系统的提交记录和问题票关联起来。