转载

百度如何开展持续集成--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各阶段的测试覆盖的组成图。

百度如何开展持续集成--CI实施方案之道

> > > >

构建系统

选择了合适的测试覆盖后,就该构建系统登场,构建系统的目的将测试覆盖,在各个测试阶段和现有资源的情况下,有效组合起来,最大程度的发挥作用,也就是让测试执行足够快和稳定,下面简单阐述下构建系统特别需要考虑的几个方面:

1、 复用:

构建系统尽量设计成复用,比如资源的复用、各个测试阶段相同测试覆盖测试框架的复用、测试环境的复用、测试产出的复用,因为复用既可以解决系统效率问题,也可以使得框架、资源统一维护,减少排查和维护的成本,对团队和CI的建设深入提供比较充分的土壤。

2、 合理设计pipeline:

测试pipeline指的是将测试覆盖有效串联起来的机制,为什么要为测试设计pipeline,主要是基于几方面考虑:

A、如果测试任务均并发,会因为由于代码问题,导致很多不该执行的任务得到执行,浪费资源和提高了排查成本。

B、 设计pipeline时,可以考虑代码变更性质而决定触发什么类型的测试,如RD提交的只是单测代码,那么系统级别测试完全可以忽略执行,从而提升效率。

3、 服务化:

这点要求对于小的产品线可能见不到收益,但是如果想将构建系统在更大范围内使用,肯定需要考虑其余产品接入成本和维护成本,这时候将测试设计成服务,显得尤其重要。

构建系统的设计还有很多需要考虑方面,这里也只是抛砖引玉,希望能够给大家一点启发。

> > > >

团队习惯

构建系统建立起来后,就需要研发、测试等相关同学围绕构建系统进行相关的研发工作,但任何系统都需要操作人员遵守一定的流程规范,持续集成构建系统也不例外,这里面特别强调两点:

1、 提 升团队对构建系统的关注度:整个团队需要对构建系统的稳定性负责,做到问题谁引入谁负责,问题及时修复,这样才能保证整个构建系统健康运转,也能发挥系统 及时发现问题及时修复的作用,如果团队对构建系统不关注,几乎是对测试结果的不信任,这样构建系统的搭建几乎是无意义的。

2、 减少因不规范提交代码对构建系统的影响:重点强调RD及时对本地代码进行测试,及时提交代码,避免因为代码量过多导致的失败,提升后续失败构建的排查成本。

想特别强调的是,团队习惯的形成,非一朝一夕,它需要团队各方面角色的配合,也需要构建系统研发人员不断迭代优化,从而逐渐将整套工具链收敛。

下图是一副持续构建系统的系统交互图:

百度如何开展持续集成--CI实施方案之道

仁者见仁,智者见智,任何道都是取自实际、用之实际,上面所提的总结和考虑,也不能一概而论,按照上述原则,设计适合产品持续集成的方案即可。

本期先介绍到这,后续文章将介绍持续集成最佳实践之破冰之旅,敬请期待。

如果你看的意犹未尽,如果你想随时随地充实自己,请扫描以下二维码,关注我们的公众账号,可以获取更多技术类干货,还有精彩活动与你分享~

百度如何开展持续集成--CI实施方案之道

原文  http://qa.baidu.com/academy/detail/article/74
正文到此结束
Loading...