持续集成: 流程指南

 /**
  * 本没有流程, 公司采用CMMI, 要求有个流程, 就写了一个
  */

Continuous Integration Process Guide

持续集成实施指南

像" 版本控制", "配置管理"一样, "每日构建", "持续集成(Continuous Integration, 简称CI)"等实践也成为现代软件开发的必备配置. 一个好的CI环境, 能够让你实时监控软件的开发状态, 随时获得可工作的软件版本, 能够提供给开发团队,管理团队,甚至市场人员快速而有效的反馈. 没有实施CI的项目, 就像黑夜中失去联系的列车, 可能凑巧能够到达目的地, 但大多数时间不知身在何处, 将驶向何方.

好的CI环境并不是唾手可得的, 但也并非无章可循. 从2001年ThoughtWorks发布第一个CI工具CruiseControl起, 近7年的时间里, 软件开发领域涌现出了大量成功的CI实践, 以及应该避免重蹈的覆辙. 一个新的项目团队应该如何从无到有的实施CI, 这个流程已日渐清晰.


一次实施过程按时间的先后顺序, 大致可分为团队组建, 现状调研, 实施, 验收, 及后续维护等几个步骤.


一. CI团队组建

先来看一下软件开发过程中, 其它相关实践的团队组成. 以配置管理为例, 通常我们会有专门的人员负责配置库的创建, 权限的分配, 分支的管理, 等等. 他们同时负责相关工具的选择, 配置策略的制定, 以及培训手册的编写等等. 这样我们的开发团队就可以把精力集中在产品开发上, 各司其职. 以我司为例, 我们选择ClearCase作为配置管理工具, 有专人负责配置库/权限/分支的管理, 而我们的开发人员只需要简单的使用客户端工具来完成日常操作即可.

另一个例子是网络管理. 拓扑结构的制定, 地址/帐号分配, 数据的备份等, 都由专业的网管人员来完成. 开发人员只需要安心的在网管人员为他们创建的便利的网络环境中工作即可.

这是一种很好的模式. 每件事情都有专业的人员来完成, 开发人员可以把精力集中在他们擅长的领域, 即产品开发上.

与此类似, 持续集成也需要不同于软件开发的技能. 除了必要的开发经验外, CI更倚重实施人员的系统管理经验. 与其它实践唯一的不同在于, 持续集成与软件开发过程结合更紧密, 定制性更强. 因此, 我们建议循序渐进, 以点带面的培养专业的CI人员.

当然在实施的过程中， 仅仅依靠掌握了CI技能的人员是不够的. CI过程中牵扯到的任何一个步骤, 可能都需要更专业的人员配合. 每个人都不可能精通所有的工具. CI的按需定制性又极强. 尤其在实施的初期, 需要精通某个专有工具的专家给予足够的支持.


综上所述, 持续集成需要不同于开发人员的技能, 可以循序渐进的培养专业人员, 并在每个项目实施CI的过程中, 得到领域专家的配合.


二. 现状调研

我们反对一成不变的照搬已有的经验. 任何忽视现状的CI实施都是不可取的. 在每个团队中, 总有一些独特的, 强大的工具让你眼前一亮. 认真了解项目组目前的工作状况, 是成功实施CI的必备步骤.

在我们的培训教材中, 我们提到, CI的实施, 需要人和工具两个方面的因素. 在调研过程中, 我们也需要考虑这两方面的因素, 做出全面的评估.

1. 人, 或者说开发文化

评估检查列表:

是否编写单元测试, 或其它形式的自动化测试?
是否经常提交代码?
是否总是在提交代码前先从服务器上更新代码?
是否关心自己提交的代码会不会导致其他成员的代码构建失败?
是否所有的团队成员都在同一间办公室工作?

其中正面的回答将有利于提高CI环境给出反馈的速度和力度, 有利于减少在CI环境中失败的构建次数.

2. 工具

2.1 评估检查列表(自动化程度):

是否有无需人工干预的单元测试工具?
是否有无需人工干预的功能测试工具?
是否有无需人工干预的更多种类的测试工具?
是否有无需人工干预的代码质量检查工具?
是否有无需人工干预的部署工具?

这里强调"无需人工干预", 而不是简单的"自动化", 是想强调不仅仅需要能够自动化的启动运行, 而且需要保证在整个运行过程中无需人工干预. 比如说:

不能够在控制台中等待输入
不能够弹出对话框等待输入

2.2 评估检查列表(可集成性):

是否能够按照惯例在发生错误的时候返回非零值?
是否能够接受一定格式如Xml或纯文本格式的输入?
是否能够产生标准格式如Xml或HTML等易于集成的输出?
是否接受命令行参数?
是否支持标准协议控制如 HTTP, FTP ?
是否支持编程访问如 RMI, CORBA, SOAP, TCP?

在持续集成逐渐发展成熟的理论中, 一个叫做"Pipeline"的概念开始得到认同. 构建过程中的每一个步骤未必是一个孤立的步骤, 可能需要接受前一个阶段的输出作为输入, 并产生自己的输出作为下一个步骤的输入, 因此基于各种标准的输入输出支持是必要的. 专有格式并不适合任何一种集成环境.

2.3 评估检查列表(透明度):

是否能够产生自己的运行日志?
是否能够指定日志的磁盘位置和格式?

CI环境需要展示尽可能多, 尽可能有用的报告, 工具的自我报告直接影响最后的效果.

2.4 评估检查列表(环境依赖性):

是否能够在硬盘上的任何一个目录中运行?
是否不依赖于绝对路径?



三. 实施

实施过程是CI的重点, 直接关系到成功与否. 却也正是变化最多的一个阶段, 定制性都在这个阶段体现. 每个CI环境都有独一无二的特点. 没有什么好的方法, 依赖于团队的经验.

在这个过程中, 在大的方面上, 可以遵循下面的原则或实践:

使用配置管理来管理配置
使用一切手段, 让反馈更快
使用一切手段, 让反馈更有效
学习并积累可复用的CI最佳实践
培养团队成员的责任感, 将CI的反馈落到实处.


在这个过程中, 可能会遇到很多问题. 典型的问题如下:

1. 无法把某个步骤自动化: 认真分析一下原因. 通常这不是真的, 除非一个软件是完全封闭的, 没有任何可编程的接口供集成. 问题可能出在选择的工具上. 是否能够改进现有工具? 是否能够选择其它工具?

2. 需要集成多个源代码源: 尽量不要让两个不同组件的源代码直接依赖, 可以使用编译后的库作为媒介. 如果必须有源代码的依赖, 尽量让它们使用同一个源代码仓库. 如果依赖的源代码必须在另外一个仓库中, 尽量选用支持聚合的源代码控制系统, 如Subversion, 可以使用 svn:external 来将不同仓库中的代码聚合在一起.

3. 需要双向合并不同分支中的源代码: 确切来说, 这是配置管理的问题. 这只是配置管理带给持续集成环境的麻烦. 从配置管理的角度, 应该尽量避免创建这种需要双向合并的分支. 一旦发生这种情况, 最稳妥的办法还是开发者在本地完成合并, 然后运行私有构建, 构建成功后再提交到CI环境监控的源代码库中.


四. 验收

CI环境一旦建好, 就会被项目组的成员天天使用. 因此环境本身的质量好坏, 会直接影响到它在监控项目状况方面的效果. 我们有一些验收标准, 用于检查一个CI环境是否满足需求. 这个列表可以随时补充新的标准

1. 配置管理: 是否使用了配置管理来管理配置?
2. 环境无关: 是否易于移植? 是否从配置库中更新下来就能用? 或者拷贝到另外一台机器上就能用?
3. 自我管理: 是否能够自动更新配置? 是否无需重启即可令新配置生效?
4. 构建速度: 主要的构建是否能在几分钟之内完成?
5. 自动化程度: 是否自动化了所有的验证, 检查步骤? 是否即使发生错误也无需人工干预?
6. 问题定位: 是否能提供线索迅速定位到出错的代码行和开发者?
7. 历史记录: 是否能够下载最后一个可用的版本? 能够下载任何一个可用的版本?

一个最佳实践就是把整个 CI 环境提交到版本控制系统中, check out 到一台新机器就能用

五. 后续维护

项目的开发周期从几年到几个月不等, 而通常开始的几个星期内就会把CI环境搭好. 随着开发的进展, 必然会对CI环境有新的需求. 如何应对这些新的需求? 可以从组织管理和技术两个方面来考虑.

组织管理:
1. 即使有专业的集成团队, 但资源不充足的时候他们需要为更大范围的组织服务, 因此项目组内部需要有至少一位成员对环境比较了解. 这可以通过在前期和专业人员结对工作来实现.
2. 随着时间的推移, 熟悉持续集成的人员必然越来越多, 可能在每个项目组内都有人熟悉持续集成. 这也是我们想看到的结果. 这意味着我司已经建立起了一支有形或无形的专业的持续集成队伍. 这支队伍中的大部分人都能够解决自己项目组中简单的集成问题. 而少数更专业的人士可以进行更大规模, 集中式的CI平台规划或管理.

技术:
1. 所选用的CI工具必须是易于扩展的, 支持用户定制的. 必要时可以通过编写插件来满足新的需求.
2. 所选用的工具最好有可靠的支持, 或成熟的社区, 碰到问题可以寻求帮助.