持续集成视频1/2在线视频

大家好

今天我们开始讨论持续集成

首先我们来看一张版本号的截图

这个截图来自于我们常用的办公软件PowerPoint

平常我们一般说PowerPoint2007，2010，2013

这里显示的是PowerPoint2010，它的真正版本号
是14

我们把14叫作主版本号，后面的0是子版本号

4760是编译版本号，再往后1000是修正版本号

一般来说，前面数字变动了，说明软件的改动很
大

而后面的数字变动则说明软件的变化很小

从上面的数字来看，PowerPoint这个软件

至少发生了几千次的小版本变化

这些数字说明微软公司的软件开发过程

它的自动化程度是非常高的

那我们一般的开发团队，小公司

能不能提高软件开发自动化的程度呢

让我们来回顾一下软件开发的一般过程

一开始开发者把软件系统分成模块

然后等所有的代码都开发完成之后再集成到一起
进行测试

随着软件技术的发展，各种软件方法百花齐放

软件规模也在扩大，软件需求越来越复杂

由于很多 bug 在项目的初期已经存在了

只是到了后来集成的时候才暴露出来

开发者需要在集成阶段花费大量的时间来寻找
bug 的根源

加上软件的复杂性，问题的根源很难定位

甚至出现了不得不调整底层架构的情况

在这个阶段，除虫会议特别多

会议的内容基本上都是讨论 bug 是怎么产生的

最后往往发展成为不同模块的负责人之间互相推
诿的情况

后来人们开发了一些脚本把相关的开发工作连接
起来

从而形成了早期的软件自动化

早期的自动化叫Daily Build

顾名思义就是每天跑一次集成

后来人们发现这种自动化的集成最好是晚上来做

这样可以避开白天的开发高峰

所有又改名叫Nightly Build

随着构建的频率越来越高

Daily Build和Nightly Build都无法表达

这种一天超过一次的构建频率

于是就改为持续构建，但持续构建这个词动作过
于单一

因为构建这个词没有办法涵盖整个软件项目的开
发过程和目的

最后就改为持续集成

当然这个词也不是很完美

持续的意思很容易让人误解

也就是说这个集成的动作是一直做下去没有停止
的

当然它的实际的意思是经常的，频繁的进行集成
的动作

说到持续集成，我们来看一下Martin Fowler

给持续集成下的那个最原始的定义

他强调团队开发成员要经常集成他们的工作

通过每个成员每天至少集成一次

也就是意味着每天会发生很多次的集成

每次集成都通过自动化的构建来验证

从而尽早地发现集成错误

这里他特意强调构建包括了编译，发布和自动化
测试等动作

持续集成最明显的好处就是可以避免

传统的开发模式那种集成阶段的除虫会议

通过持续集成，绝大多数的Bug

都可以在引入的同一天被发现

由于一天当中程序员改动的代码并不多

所以可以很快的找到出错的位置，并消除bug

总之，持续集成可以减少集成阶段"捉虫子"所消
耗的时间

可以加快发布新版本的频率

从而最终提高生产力和软件质量

下面我们看一看，一个典型的持续集成流程是如
何进行的

首先，开发人员在完成了代码编写之后

向版本控制库提交代码

在提交代码之前，需要在本地机器上执行一次私
有构建

来确保自己的代码修改是正确的

同时，集成服务器会不停的轮询检查

版本控制库中的代码变更

一旦检测到有代码变动

CI服务器就会从版本控制库中拉取最新的代码

到集成服务器上去

然后执行构建脚本，对软件进行编译

单元测试和代码规范检查

甚至包括自动化文档生成等一系列的动作

完成了所有的工作之后，CI服务器根据构建结果

向特定的项目成员发送电子邮件，反馈持续集成
的结果

比如向项目经理发送集成的摘要信息

向发现了Bug的源代码的作者发送bug信息等等

然后CI服务器继续监控版本控制库中的代码变更

等待进入下一次持续集成

从这个典型的持续集成流程中大家可以看出

任何一个集成环境都应该具备四个特征

与版本控制系统的连接，构建脚本，反馈机制

以及集成源代码变更的过程

在公司实行持续集成不是一件容易的事情

那么是什么吸引着我们去做持续集成呢？

这就需要提到持续集成能够带来的价值

首先是减少风险

如果我们可以一天进行多次构建

就可以有效的减少项目的风险

因为CI每天进行多次集成并执行了测试和审查

所以在缺陷引入的时候就很有可能发现它们

同时通过收集项目的信息

就可以对项目进行接近实时的追踪

也就是说，持续集成提供了一张安全网

降低了缺陷进入代码的风险

其次是减少重复过程

减少重复过程可以节约时间，费用和工作量

让人们有时间去做那些需要动脑筋的

更具有价值的工作

第三，可以生成可部署的软件

对于客户来说，他们其实并不真正的关心

我们团队内部是如何做的

他们更关心的是能不能可以看到实际跑的软件产
品

不采用CI的项目可能需要等到交付之前

才能对软件进行集中的测试和集成

这可能会延迟产品的发布，甚至会导致项目的失
败

CI的第四个价值就是增强项目的可视性

我们前面说过，未知会引起恐惧

如果我们能够通过CI获取当前的构建状态和品质
指标

获取软件当前的缺陷率和功能完成情况的统计

就有助于管理者和客户了解软件产品的开发进展

从而做出更有效的决策

并能够及时对项目的发展趋势做出正确的判断

最后，成功的CI可以给软件开发团队带来更大的
信心

每一次成功的构建都会告诉我们的团队成员

他们的工作通过了测试和验证

他们的代码符合了项目编码标准和设计标准

他们距离成功又近了一步

如果我们的团队要实施持续集成

应该注意以下这些CI实践

CI的核心原则是“早集成，常集成”

所以我们要提倡开发者更加频繁的提交代码

把任务分解成更小的工作

每个任务完成之后马上提交代码

避免在下班前集中提交，从而避免引起更多的构
建错误

开发者在提交代码前，要确保自己在本机上完成
了私有构建

并且完成了所有必需的单元测试，通过了代码覆
盖率检查

代码编写规范检查等等

在CI环境下，每个错误都是以增量的方式被发现
的

因此很可能是个小的错误，很容易被修复

而且在团队中要求大家把修复构建错误

作为优先级最高的事情来做

以避免影响团队中其他成员的工作进度

特别需要注意的是，当构建失败的时候

不要从版本控制库中签出新的代码

否则，你就无法编译和测试你自己的代码

而别人的错误你又无法解决，只能想办法绕过去

实际上，引起构建失败的开发者可能正在紧锣密
鼓的

修复他们自己的代码，或者正打算将修复好的代
码

提交到版本控制库

所以，虽然构建失败可能会导致开发者的工作有
一个短暂的停滞

但是总比签出带有错误的代码而无法继续工作要
好一些