《敏 捷 教 练：如何打造优秀的敏捷团队》—10.2 持续集成

10.2  持续集成

你会发现，开发人员都习惯了各干各的活，隔几天提交一次代码。他们迟迟不肯集成代码是因为集成很耗时间，可是，代码库其他部分在他们推迟集成的这段时间里也会发生变化，于是，间隔时间越长，集成也就变得越困难了。

持续集成(Continuous Integration，CI)就是尽早且频繁地集成代码变更。每次集成都很小，所以集成起来也很轻松。使用此方式，每完成一小段代码，就能很快地更新给整个团队，而不是一次更新一大段。CI和TDD也有关联，因为测试需要在全集成代码库上运行通过，只在某开发人员的电脑上通过测试可不够。因此，CI不只是要频繁地集成代码，还需要所有测试在任何时候都能运行通过。

正如詹姆斯·肖尔(James Shore)所说[1]：

主流观点认为持续集成是一个工具，恰恰相反，它不是工具，它是一种态度。它是团队达成的共同约定：

1.   我们从版本库中获取的最新代码要能构建成功并通过所有测试。

2.    我们每2到4个小时提交一次代码。

我们很喜欢这段引语，因为采纳CI最重要的部分就在于所有团队成员都全身心拥抱这种理念，确保所有测试一直都能运行通过。若团队尚未端正此态度就立即开始使用CI工具，开发人员通常都不负责修复失败的构建。

团队引入CI时，提议他们首先得遵守一个同步式CI流程。每次开发人员提交代码后，都要先执行构建，等到所有测试都通过之后再继续开发代码。如果有测试没有通过，开发人员就得去修复问题。

此方法能否奏效，取决于开发人员能否消除同时集成变更这种互相踩踏的行为。有很多团队都在使用构建令牌，它可以是任何物品，只要能让团队一看到它就知道正在集成就行。这能给团队带来些欢乐，有助于把CI流程变成团队惯例。我们曾见过团队使用橡皮鸡、哞哞牛和滑稽帽，甚至包括图10.2中用索引卡做成的“集成之剑”[2]。

图10.2  构建令牌

也有些团队还弄出声音来庆祝成功的集成，像一声锣响或是鼓掌声之类的。对于团队其他成员来说，这是一个信号，意味着刚提交的代码现在可以拿了。

尽管这种同步式CI流程听起来更耗时间，不如让软件检测代码提交并自动运行测试那么快速，但这样做的好处在于，能帮助开发人员学着承担修复失败构建的责任。一旦团队所有人每天都集成代码好几次，而且构建也不再频频失败，就该选择一种软件辅助的异步解决方案了。密切注视团队是否会承担责任修复失败的构建。重点在于改善构建状态的反馈机制，以便在构建失败时能让团队第一时间知道。

改善构建状态的反馈机制

如果团队开始使用某个CI服务器执行构建并发送测试结果，就不需要构建令牌。开发人员提交完代码就可以继续干活了。现在，由于他们最新的代码提交可能会导致测试失败，所以，重点在于一旦构建失败就向所有人发出警报。要让开发人员知道测试失败，邮件提醒可能不一定是最佳的方式，因为他们在编程时很可能会关闭邮件客户端。相反，学习Ivan的做法，把构建页面弄得更有意思，突出显示失败的测试以便所有团队成员都能看得见。图10.3就是某个构建页面的一张截图。

反馈需要又快又明显。如果运行所有测试要花很长时间，就等它完工，到时可能会有更多开发人员提交代码。通常不会有人跳出来修复它，因为所有人都觉得是其他人在破坏构建。