Question

10.1.1　持续集成的简介

◉ 开发流程中存在的风险

持续集成是一种让计算机自动地任意次重复整个开发流程（编译、测试、汇报等）的开发手法，一般简称为 CI。由于其频繁重复整个开发流程，所以能帮助开发者提早发现问题。

为方便理解持续集成，现在我们把从写代码到向执行环境发布的整个开发流程大致分为以下 3 个阶段。

① 编写源码。修改已有代码

② 提交、push

③ 进行发布

在②和③的过程中容易出现下述问题，必须严加注意。

· 遗漏提交。忘记提交要发布的程序

· 遗漏合并。push 到 default 的时候忘记合并，出现多头现象

· 遗漏安装。编写的程序需要特定 Python 模块才能运行，但是忘记安装该模块了

对于这类问题，只要事先准备好测试代码，在程序发布到目标环境之前执行测试，基本都能被发现。

◉ 长期开发中容易出现的问题

我们都希望测试代码在发布之后仍能够长期继续使用。毕竟开发是一个持续的过程，一次发布之后还会有下一次发布，并不是发布一次就结束了。

在开发长期持续的过程中，我们会遇到下面这些问题。

○ 忘记以前发布的代码

肩负程序修改任务的开发者对源码的修改十分敏感，会频繁地执行测试代码。可是，一旦修改任务结束，问题关闭，就很少有人再愿意回过头去手动执行那些已经通过的测试了。

○ 只关心自己负责的部分

大部分时候，我们会去执行与自己负责部分相关的测试代码，但不会关心责任范围以外的模型的测试。然而，我们对程序的修改有时会“枪毙”掉某些看似毫无关系的模块的测试结果。估计各位之中有不少人有过类似经历。

可见，我们很难通过人为的注意和操作来确认整个开发流程，而且这样做也是一种时间和劳动力的浪费。如果项目代码量很大，那么执行所有测试代码必然消耗大量时间，如果是在自己的环境中执行，这根本不现实。所以这类工作最好交给计算机去做。

◉ 一天内多构建几次能很快发现问题

一天内多次定期 pull 源码并运行测试代码可以帮助我们及早发现问题。与其等到后期一次性找出一大堆问题，不如在产生问题时及早处理来得方便和放心。这一做法被我们称为持续集成。

NOTE

持续集成是XP（Extreme Programming，极限编程）的最佳实践之一。原文出自 Martin Fowler1 的论文，各位可通过下述 URL 查看2 。

1 国际著名的面向对象分析设计、UML、模式等方面的专家，敏捷开发方法的创始人之一，现为 ThoughtWorks 公司的首席科学家。——编者注

2 中文版论文请参考如下网址：http://www.cnblogs.com/cloudteng/archive/2012/02/25/2367565.html 。——编者注

Continuous Integration

http://www.martinfowler.com/articles/continuousIntegration.html

10.1.2　Jenkins 简介

Jenkins 是基于 Java 的开源 CI 工具，其安装和操作都很简单。另外，Jenkins 不仅能在面板上轻松看出 Job 成功或失败，还可以借助通知功能将结果以邮件或 RSS 订阅的形式发给用户。

除此之外，Jenkins 还允许通过插件进行功能扩展，所需功能可以随用随添加，而且还支持主从式集群，能够轻松地横向扩展。

下述流程是用 Jenkins 实现持续集成的一个例子。本章我们将根据下述流程进行学习。

· 为 Job 的执行制定日程表

· 签出源码

· 通过 shell 脚本执行测试（包括检测覆盖率）并输出结果

· 通过 shell 脚本构建文档

· 统计测试结果和覆盖率

· 统计 TODO

· 发送邮件通知 Job 的结果

· 将 Job 的结果保存至 Slack