百度如何开展持续集成--CI实施方案之道
百度如何开展持续集成序列文章一，已经给大家介绍百度如何撬动产品线壁垒，形成统一方向和目标，并给出方向指引，就是建立通用的CI能力模型，从CI三大要素，测试覆盖、构建系统、流程规范几个方面定义了可量化的核心指标，本文重点介绍CI从这三方面实施方案之道。
详情 ↓
> > > >
测试覆盖：
测试覆盖是持续集成的灵魂，在这里就不在重复解释，那对于被测产品面对代码检查、单元测试、功能测试、性能测试、压力测试、 UI 测试、接口测试、集成测试、安全测试等多种测试类型，如何合理的选择是制约着持续集成快速建立的关键因素，下面给出选择测试覆盖的几点考虑：
1、 整体和部分融合：持续集成首先要体现集成重要性，大到产品线包含的各个子系统，小到模块内部各个类或函数，从某种意义上理解，产品就是由多个子系统有效集成 的，模块是由众多类有效集成的，所以在考虑在产品线的测试覆盖时候，不仅要考虑产品级的测试覆盖，也需要考虑针对各个类或函数的测试覆盖，因为在最细粒度 的级别做好质量保证，才会将众多的问题提前暴露，从而降低问题定位和修复的成本，不至于问题到子系统集成才发现，而影响产品发布；但是整体性也需要特别考 虑的，产品毕竟是整体对外发布，需要对整体做有效的集成测试才有信心对外发布，以下是百度某产品线对选择的测试覆盖类型：
A、 代码检查：针对代码层面的白盒分析，解决代码风格，基本语法等问题，也可以解决代码的安全性、不规则使用库函数等问题，这类问题在其余测试类型可能无法或不方便覆盖。
B、 单元测试：引入这种类型的考虑主要一是降低RD自测成本，二是用单测试去覆盖复杂的策略和算法逻辑，比起用功能测试去覆盖具有数据易构造、覆盖更充分的特点。
C、 功能测试：功能测试主要是对单测不便覆盖的功能进行补充，如网络交互、流程性函数、模块启动和日志打印等等。
D、 性能测试：A、B、C考虑的集成是类的集成，性能测试会站在子系统的角度，将1个或多个模块集成起来，做性能分析，用于保证代码升级对子系统带来的性能影响。
E、 压力测试： 压力测试也是面向子系统的，主要测试子系统的稳定性，如CORE、FATAL、内存泄露等情况。
F、 产品集成测试：产品集成将多个有效的子系统搭建出来，统一进行压力测试，关于为什么目前只做了压力测试，在接下来会有大概的解释。
2、 高效且稳定：
这两点想必大家理解起来会轻松点，高效：指RD一次提交到最终收到质量反馈要足够高效，如果效率较低，则会影响整体RD提 交代码的习惯严重的更会影响产品发布周期。稳定：指任何一项测试都要形成闭环，每次任务执行都有基本的正确与否的结论，但正确与否的结论希望尽量不受测试 框架和外界影响，只有这样测试结论才会得到认可，并提升团队对测试的信心。上面提到产品集成测试只选择压力测试也是基于这点去考虑的，因为性能和功能测试 的结论太受线下环境准确性和网络环境的影响，而这些影响也很难避免，基于综合考虑前期会先在产品集成的时候去掉性能准确性测试。
3、 符合产品线现状：
这点考虑主要是为了达到产品研发模式或者产品业务特点的情况，设计出的一些比较合理的测试覆盖，比如为了测试出NA在任意机型下都能安装，可能测试覆盖需要加兼容性测试，为了评估算法好坏需要增加策略效果评估测试，为了适应主干开发模式下，保证多位RD在同一代码路径下开发的代码不相互影响，可能需要增加query-diff测试等。
以上几点是百度在实施持续集成的提炼的一些经验总结，也很欢迎各位提建议，完善整个测试覆盖的选择之道。以下是百度某产品线制定的CI各阶段的测试覆盖的组成图。
> > > >
构建系统 ：
选择了合适的测试覆盖后，就该构建系统登场，构建系统的目的将测试覆盖，在各个测试阶段和现有资源的情况下，有效组合起来，最大程度的发挥作用，也就是让测试执行足够快和稳定，下面简单阐述下构建系统特别需要考虑的几个方面：
1、 复用：
构建系统尽量设计成复用，比如资源的复用、各个测试阶段相同测试覆盖测试框架的复用、测试环境的复用、测试产出的复用，因为复用既可以解决系统效率问题，也可以使得框架、资源统一维护，减少排查和维护的成本，对团队和CI的建设深入提供比较充分的土壤。
2、 合理设计pipeline：
测试pipeline指的是将测试覆盖有效串联起来的机制，为什么要为测试设计pipeline，主要是基于几方面考虑：
A、如果测试任务均并发，会因为由于代码问题，导致很多不该执行的任务得到执行，浪费资源和提高了排查成本。
B、 设计pipeline时，可以考虑代码变更性质而决定触发什么类型的测试，如RD提交的只是单测代码，那么系统级别测试完全可以忽略执行，从而提升效率。
3、 服务化：
这点要求对于小的产品线可能见不到收益，但是如果想将构建系统在更大范围内使用，肯定需要考虑其余产品接入成本和维护成本，这时候将测试设计成服务，显得尤其重要。
构建系统的设计还有很多需要考虑方面，这里也只是抛砖引玉，希望能够给大家一点启发。
> > > >
团队习惯 ：
构建系统建立起来后，就需要研发、测试等相关同学围绕构建系统进行相关的研发工作，但任何系统都需要操作人员遵守一定的流程规范，持续集成构建系统也不例外，这里面特别强调两点：
1、 提 升团队对构建系统的关注度：整个团队需要对构建系统的稳定性负责，做到问题谁引入谁负责，问题及时修复，这样才能保证整个构建系统健康运转，也能发挥系统 及时发现问题及时修复的作用，如果团队对构建系统不关注，几乎是对测试结果的不信任，这样构建系统的搭建几乎是无意义的。
2、 减少因不规范提交代码对构建系统的影响：重点强调RD及时对本地代码进行测试，及时提交代码，避免因为代码量过多导致的失败，提升后续失败构建的排查成本。
想特别强调的是，团队习惯的形成，非一朝一夕，它需要团队各方面角色的配合，也需要构建系统研发人员不断迭代优化，从而逐渐将整套工具链收敛。
下图是一副持续构建系统的系统交互图：
仁者见仁，智者见智，任何道都是取自实际、用之实际，上面所提的总结和考虑，也不能一概而论，按照上述原则，设计适合产品持续集成的方案即可。
本期先介绍到这，后续文章将介绍持续集成最佳实践之破冰之旅，敬请期待。
如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
