来源 | 百度QA（baiduqa）
持续集成这个词大家一定不会陌生，其官方定义为: 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员至少每天集成一次，也就是意味着每天可能会发生多次集成，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而快速地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成的意义、效果等就不在此详解，这里主要根据在百度实施持续集成过程中的积累，和大家分享下对于持续集成实施的一些理解，欢迎大家共同探讨。
百度公司自2010年开始逐步在如凤巢、网盟等大型产品线实行持续集成，并且取得了良好效果，近几年随着公司的不断发展，新产品不断涌现、充分市场化的竞争逼迫产品迭代速度不断提升，公司越来越多的产品线希望能够通过持续集成去保证质量、提升产品效率，然而持续集成非一朝一夕之功，需要长时间的尝试和沉淀才能发挥其更大作用，为了缩短产品线切换持续集成的时间，避免走弯路和重复造轮子导致的效率低下问题，百度成立了CI小组，其成员大部分来自CI实施效果较好的一线产品线，旨在通过提炼已有产品线实施CI的方案、建立CI工具链，服务于公司所有产品线。
面对公司上百条产品线，我们解决思路主要如下：
首先要解决方向性和如何开展实施问题，根据对百度已有产品实施CI经验和CI特性深度分析，建立了CI能力模型，该模型主要给产品线以方向指引，其次模型是根据CI主要特点分维度建立的，也具有一定实施指引作用。
方向明确后，下一步需要给出CI指导方案，让产品线基本可以参照执行，从而能够复用更多优秀的经验和方案，避免走弯路。
CI能力模型和指导方案毕竟是从部分产品线提炼而来，也存在漏洞与不足，因此团队也专门让相关成员实际参与新产品线的持续集成开展，以便逐渐完善方案。
方案更多的是理论层面的指导，为了加速CI落地，同时我们也会根据产品形态、开发语言等情况，建立对应的工具链平台，以支撑CI的快速实施。
最终我们也建立了CI人才成长体系，从四个方面去依次突破，形成CI的生态：CI人才利用CI技术支撑产品线开展持续集成，也不断打磨CI工具链，进而达到产品线和百度CI能力提升双赢。
本期先介绍CI能力模型，后续会有其余三部分的详细介绍。通过对持续集成的经验积累，基本可以把持续集成认为具有如下几个特点：
持续集成是一项开发实践；
持续集成的目的是保证一个随时可以正常工作的系统；
通过小的改动，逐步的构建系统；
至少每天集成；
工作在主干上；
使用自动化测试 。
综合起来持续集成的目标就是保证质量的前提下，尽量提升效率，极致状态保证随时可以发布的产品。其主要有三大核心因素：完善的测试覆盖、高效的构建系统、规范的项目流程。测试覆盖是持续集成的灵魂，没有测试覆盖持续集成就是空壳，没有任何意义；构建系统是把流程和测试覆盖用合理的方式自动化起来，从而提升效率，构建系统的优劣也制约着效率提升的程度；最后所有项目成员围绕一定的流程规范在建立好的构建系统工作，达到正常状态。测试覆盖、构建系统、项目流程的实施方案在接下来的章节会有体现，这里主要讲的CI能力模型也是依据这三者设计的，主要原因是：方便用户理解模型、用户对于CI如何开展也可以根据这三者去铺开。下面具体介绍各个指标及其物理意义：
1测试覆盖：
将项目流程基本划分为local、trunk、daily、rb、pre-online五个阶段，每个阶段产品线都需要注入对应的测试类型如代码检查、单元测试、功能测试、性能测试等等，由于产品形态的不同，所选测试类型也不同，因此模型没有规定产品增加什么测试类型，只是对测试类型的个数有要求。为了进一步验证测试类型的效果，我们通过统计测试覆盖率去评估测试效果，因此测试覆盖有如下指标：
本地测试(local)：用于RD保证未提交代码的质量。
主干测试(trunk)：用于保证提交后merge代码的质量。
集成测试daily：用于保证产品线多模块间集成的质量。
灰度发布pre-online：用于保证具备产品随时可以发布能力。
测试覆盖率cov：用于衡量添加测试类型的实际效果。
2构建系统：
构建系统需要考虑如何将各个测试阶段的测试类型集成起来，合理的执行以最大程度的缩短提交测试到结果呈现的时间间隔，快速，稳定的完成是对构建系统的基本要求，因此用以下指标去衡量：
编译时间： 编译是持续集成的源头，所以专门对编译时间做了考核，以促使产品改进。
构建时间：衡量所有任务执行时间，正常不能超过1h。
主干成功率：衡量主干测试任务成功率。
异常构建率：衡量非代码因素导致的失败率，用于促使工具提升稳定性，增强构建系统信心。
daily成功率：衡量集成测试任务成功率。
3团队习惯：
团队习惯体现的是团队对持续集成的关注度和理解水平，主要有以下几项指标：
主干开发： 主要目标希望产品线减少分支开发，以减少代码维护和merge的成本。
ci频率：主要目标是希望RD能够通过频繁提交代码，达到快速集成的目的。
MTTR：主要体现团队成员对失败任务的重视程度。
为了减少主观因素干扰，所有指标的设计都做到数据可采集和可量化，CI能力得分等于每项维度得分相加，为了进一步提升CI能力模型方向指引作用，也对CI能力模型进行分级，主要参考如下：
百度自2015年CI能力模型公布以来，所有产品线都根据自身现状，积极开展持续集成，公司水平提升20+分，为公司研发效率提升提供了重要保障，为了摸底产品线真实情况，每个季度依次按照准入、初评、访谈、讨论、沟通、定级、总结7个阶段进行对产品线CI能力进行评级，以便更好地掌握公司CI现状。
最后特别强调，CI能力模型评估出的得分和等级不是终点和目标，模型是用来衡量产品线实施CI的标尺，以便产品线更好有目的的改进，一切分数皆尘土，产品线迭代效率的提升才是王道。
本期先介绍到这，后续文章将介绍持续集成实施方案之道，敬请期待^ ^