上一篇中我们总结了价值流图中变更管理的基础技术手段之一：版本控制，本篇我们继续总结变更管理的基础技术手段之二：持续集成。

持续集成意味着团队的所有成员以每日至少一次的频率将自己的代码变更集成至中心代码库并通过自动化的构建和测试来验证变更质量，以尽可能早和快的发现问题。持续集成与版本控制配合完成了对软件开发过程的持续质量保障，二者缺一不可。最常见的比如jenkins和gerrit的配合，每个提交到gerrit的change都能触发jenkins的job，而job运行完成后可以根据结果对gerrit的change进行review&verify 打分，以反馈验证结果。

如果说需求管理是持续交付的引子，版本控制是持续交付的基础，那么持续集成就是持续交付的核心。持续集成不仅仅保障了开发过程的代码质量，而且通过持续集成工具对上游代码变更的监控和对下游触发任务的编排，持续集成将持续交付流水线前后贯穿并使其流动起来，使得“每一次代码变更都能生成一次可用的软件版本”成为可能。

如今国内大大小小的软件开发公司都已用上了基本的持续集成功能，因为它的投入代价实在太小而获得收益实在太高。首先总结一下持续集成耳熟能详的两个基本功能点：第一，轮询监控版本控制库并触发任务；第二，可视化展示任务结果。

然后我们尝试深入思考一下持续集成实践中遇到的一些问题和解决思路： 

1.分支策略

持续集成所面向的对象实际上是中心代码库里某一条分支的全部或部分代码仓库，即持续集成是以分支为部署粒度的。分支策略的选择会极大地影响持续集成的资源投入和效果收益。

通常我们能看到三种分支策略：

Ⅰ 主干用于日常bug修复，新特性开发工作在特性分支上进行，商用版本发布在发布分支上进行；所有特性分支和发布分支所合入的特性和bug都以一定的周期合并回主干。

Ⅱ 主干同时用于新特性开发和商用版本发布以及日常bug修复，没有额外的分支。

Ⅲ 主干用于新特性开发和日常bug修复，商用版本发布在发布分支上进行；发布分支仅合入bug修复并且确保所有修复合并回主干。

就目前而言，第三种分支策略综合考虑比较实用，既保障了商用版本发布的稳定，又避免了过多的特性分支与主干合并的致命问题。在主干上进行新特性开发通常会通过特性开关或者增量式开发来规避新特性对主干质量的影响。

2.分层协作

通常持续集成会分为如下几层：个人构建；组件构建；集成构建；版本构建。

不同层次的构建负责的验证范畴不同，比如个人构建关注基本的静态检查，组件构建关注本组件的质量，集成构建关注本组件与其他组件的配套关系，版本构建关注多个组件构成的整体版本功能。

比较令人头疼的是持续集成过程中不同对象的协同，我们列举三种常见情况。

2.1 同一个组件下不同代码仓库的协同构建

有时候一次缺陷修复会同时涉及多个代码仓库，对应代码变更会生成多个change记录，如果持续构建将这些change分开单独验证，结果自然是失败的。因此需要保证相关联的change记录使用相同的changeid，并在持续集成系统中定制实现按照changeid查询所需要验证的change列表，对change列表中的所有change同时进行验证。

2.2 不同组件的协同构建

考虑上面提到的集成构建，需要对不同组件之间的配套关系进行验证，此时需要确认不同组件间协同构建的策略。通常我们需要持续维护各个组件的稳定状态制品库，并选择制品库中最新的稳定版本来满足其他组件的验证需求。

但是这种策略面对同一次代码变更涉及多个组件的场景时又无法满足，所以还需要进一步思考。

2.3 代码与测试用例协同构建

面对代码变更涉及测试用例变更的场景，需要保证测试用例跟随代码变更同时验证和生效，才能避免持续交付流水线的无意义失败。因此我们需要借助敏捷开发模式，开发和测试团队融合工作，将测试用例也纳入持续集成范畴。比如可通过测试用例变更与代码变更使用相同的changeid来保证二者同时被验证。

3.团队文化

持续集成不仅仅是技术手段，更是一种团队文化。它的重点在于：频繁的小型提交；提前本地构建验证；足够快的自动化测试套件；修复失败构建为第一要务；实时构建状态公开；......