持续集成: 实践指南

 　

第一部分. 实现

　

0. 持续集成工具的作用

降低风险? No
提高质量? No
快速反馈? Yes !
工具本身并不能降低项目风险, 提高代码质量. 工具唯一能做的是给你快速反馈. 你收到反馈之后的行为, 才是降低风险, 提高质量的关键 (好几天不check
in, 工具再牛也白搭; 失败的build不修复, 工具也无能为力)
所以持续集成是一个以人为核心的过程, 工具只是在这个过程中我们要用到的一个产品, 而且绝对不是唯一的一个.
　
快速反馈: 快速反馈实际上是两个词, 快速 和 反馈, 而持续集成又牵扯到人和工具两个方面, 所以一个好的持续集成过程, 至少需要从四个方面来实施和改善:

工具如何做到快速

工具如何进行有效反馈

人如何做才能让反馈更快速

人如何做才能让反馈更有效
　

1 工具如何做到快速

1.1 监测各种变化 (拥抱变化是敏捷的态度之一, 持续集成工具正是来实证这种态度的产品)

基于源代码的变化: check in, 工具必须支持多种版本控制系统

基于依赖项的变化: 项目A的变化将触发项目B的构建, 工具必须能管理项目之间的依赖

基于其它资源的变化: 文件系统, Http资源(Server startup)... 这不光是持续集成的关注点, 多数EAI系统都基于外部资源的变化来进行集成

基于时间的变化: Nightly Build (你早上上班刚进办公室, 它就给你反馈了, 不占用你任何工作时间, 够快的吧)

基于心情的变化: 你很着急, 想立马看看你这次check in的结果, 而不是等过几分钟后让工具来调度, 工具必须支持"强制构建"

　
1.2 尽其所能来加速构建

多线程: 在一台强大的server上多线程的来并发构建多个项目

分布式: 利用网络中其它机器的资源, 并发的构建多个项目, 或一个项目的不同部分.

虚拟机: 除了可以并发构建外, 主要是能够实现环境的隔离

分阶段构建: 可以看做项目间依赖的一个变种, 支持用户将一个项目分为多个阶段, 阶段A构建完毕可以触发阶段B的构建,
但即使阶段B还没有结束而此时有新的check in的话, 阶段A会再次得到触发而无需等待阶段B结束. 典型应用场景是单元测试和功能测试分为不同阶段.

　
1.3 支持动态更新的配置或自动加载用户更改的配置

支持在线修改配置

用户修改了项目的配置, 应立即生效, 不需要重新启动CI Server

保存用户配置的历史版本, 方便用户修复自己在配置过程中不小心引入的错误
　

2. 人如何做才能让反馈更快速

2.1 频繁check in
但有个平衡或折衷, 每次check in应该保证完成了一件相对独立的事, 尽量不要把一件事放在多次check in中, 否则一旦需要revert,
就需要更多的步骤.
2.2 check in token
这可以看作频繁check in带来的问题之一. 这与CI工具无关. 这对整个团队的效率有帮助
2.3 优化构建脚本或代码
避免不必要的 #include
增量构建等. (这儿有个取舍, 通常CI环境中两次构建应该是互不影响的; 开发者可在自己机器上进行增量构建)
　

3. 工具如何进行有效反馈

3.0 不推荐电子邮件, 不到万不得已不要使用

邮件是异步的, 不及时

受SMTP服务器和邮件客户端影响, 不稳定

通常淹没在其它邮件中, 不注目

太依赖于用户坐在电脑前, 不灵活
3.1 声音与颜色, 光线 (速度分别是340m/s和30万公里每秒)

为失败的构建播放令人不想再听到的音乐

配合文本朗读引擎, 念出破坏构建的人的名字

熔岩灯

大显示屏, Web 界面
3.2 桌面通知程序

CCTray

Yahoo Widget

Firefox Plugin

IDE Plugin

RSS Reader
3.3 反馈不只是构建结果, 还包括构建过程中发生的事情

提供构建输出或log

提供触发构建的源代码变化信息, 如版本号, 提交者, 提交注释, 甚至内置diff功能

提供构建统计信息, 如构建持续时间, 剩余时间等
　

4. 人如何做才能让反馈更有效

4.1 工作空间
为了更好的利用声音/光线等反馈手段带来的好处, 团队所有人都应该在同一间屋子里
即使没有CI, 如果没有CI, 失去了CI作为纽带, 团队反而更应该待在同一间屋子里, 快速解决任何人遇到的任何问题
4.2 自动化测试
CI工具能给我们什么反馈, 不是CI工具决定的, 而是我们自己决定的. 你写的测试越少, CI工具给你的反馈也就越少
4.3 自动化一切能够自动化的东西
同样道理, 你让CI工具做的越多, 它给你的反馈就越多. CI工具的好处就是, 它可以执行脚本,应用等任何操作系统支持的东西.
4.4 Claim Responsibility
当构建失败时, 要有人迅速作出反应, 告诉大家说我会修复, 这样会避免要么大家都在等别人修复,要么有多个人都在独立修复, 浪费时间
　

第二部分, 使用

　
上面是持续集成实施者的角度来看待持续集成. 那么从用户的角度, 我们用持续集成来做什么? 我们有哪些需求需要持续集成来满足?
　
如果我是项目管理者

项目当前状态, 成功或失败

代码测试覆盖率等质量指标

构建频率, 侧面反映开发效率

在所有我的产品支持的目标平台上进行构建

最新版本的产品演示, 意味着需要编写部署脚本让CI工具把产品部署到产品或演示环境中.

　
如果我是开发者

构建结果, 测试运行结果, 失败原因

构建相关的版本控制系统里的信息, 能够快速发现是谁的check in导致的构建失败

能够按预先定义的规则在版本控制系统中加标签

Personal build, 最好是帮助我在check in之前运行构建, 成功后自动帮我check in

支持尽量多的版本控制系统和构建工具
　
如果我是Tester

能够下载任意版本的产品进行安装测试
　
如果我是CI环境维护者

提供UI, 命令行, 配置文件, 数据库等多种方式来进行环境配置

详细而精确的调试信息, 便于快速修复CI环境

CI Server的容错, 对历史数据的智能管理

易于扩展

权限管理, 不希望关键配置信息被无意修改破坏, 不希望无限制的强制构建
　

第三部分, 目标

　
所以持续集成是一个专门的领域, 但对于用户来讲, 它只是手段, 不是目标
什么是目标? 我们的产品. 所以我们会结合实际, 按照开发过程中出现的需求以最小的代价来实施符合我们需求的CI环境.
持续集成本身没什么技术含量, 但具体细节太多, 我们不建议项目中的每个人都能够实施持续集成, 牵扯太多精力, 这与软件开发几乎是不同的领域,
术业有专攻, 能够实施持续集成也不是什么大不了的事, 门槛很低, 就是体力活.
但是, 也可以说所以, 我们建议建立公司范围的持续集成团队, 或者公司比较大的话至少是部门范围内的CI团队, 为范围内的所有项目搭建统一的持续集成平台,
就像公司的IT部门, 测试部, 质量管理部一样. 这样能让项目组的人员集中精力在我们的核心业务, 我们的强项, 也就是产品开发上.