闲鱼从2014年创立,到2022年已经走过了8个年头,闲鱼APP也随之逐渐复杂。在这其中,我们也面临着大型APP共性的一些通病,例如:团队规模变大带来的研发效能瓶颈的问题,大量历史代码带来的代码腐化问题等。从解决实际问题出发,闲鱼终端团队和质量团队一起协作在2022财年进行了CI能力体系化建设,并已经通过在单测,代码质量,自动化测试&回归等方面的建设,形成了一整套的能力沉淀。通过这些能力,我们成功在闲鱼终端研发场景下实现了代码质量的稳步的提升,并在部分仓库现了向类主干开发模式的切换。本文将分享整个能力建设的过程以及我们在其中的思考,希望能给大家带去一些借鉴。
千头万绪的开始
开始接到这个命题的时候,我们都陷入了轻度迷茫。因为项目一开始就遇到了不少挑战:
1. 基础设施能力不足
首先从能力上说,集团的主要CI能力是围绕服务端和前端展开的,面向客户端的能力非常有限。这里不要说单测,简单的代码静态检查也是没有的。闲鱼之前也机会没有类似能力储备,一切都要从零开始。
2. 项目执行成本高
虽然整个过程团队的TL层给与了很大的支持。但是作为一个技术项目,且涉及各团队的同学共同协作,在推进过程中总会被这样或者那样更重要的事情打断。整体项目执行层面的成本是高的。
3. 固有观念的阻碍
如果其他的问题都可以通过“勤奋”来克服。但是很多同学心目中的“单测无用论”,“自动化是KPI”,“又不是不能用,等出问题再说”等观念已经根深蒂固,这是项目组要面临的更大的挑战。我们非常担心大家在执行过程中是一种机械式配合,而不是真心认同。如果还要消耗个人情谊,做“纯友情支持”,就更加不是我们想要看到的。
仰望星空,脚踏实地
当然困难虽然多,事是要干的。通过跟大家的沟通,其实CI能力不好覆盖,最为核心的阻力还是“成本”。做CI体系建设,就不可避免的要建立各种自动化测试的能力。所以动手之前,还是得先好好算一算账。到底自动化测试(包括单测和UI自动化)的成本高还是低?
确定性收益:
做个简单的归纳,核心收益来自于:
1. 问题发现的前置。这里不仅仅反应在问题解决效率上,更加体现在真金白银的花费上:
一方面是:越往后发现问题往往需要越多重复性的回归测试投入(如下图所示) 另一方面是:越往后往往意味着越多的协同。如果到了临近发版再出问题,那可能就需要开发,测试甚至业务同学一起协作解决了。这样的成本也会大幅提升。
2. 规模化验证下的巨大效率提升
从功能数量和回归次数两个角度,可以清晰对比出自动化测试在规模化以后的巨大效率提升。【《持续交付 2.0》】
3. 其他优势
机器相比于手工回归,具备随时随地回归的特性。开发同学能从中获得极具幸福感的开发体验:快速反馈,快速迭代。同时为了提升CI覆盖的效率,开发往往会被倒逼进行更好的接口设计,架构优化。代码结构往往更好。
此外机器回归还具备结果稳定性高,拓展测试的深度和范围(能尽可能发现底层问题),覆盖纯手工无法覆盖的场景等等的优势。
直面成本:
首先必须承认自动化能力(包括单测和UI自动化等)的开发,需要投入更多成本。这里包括一次性的成本和后期迭代的外投入的成本。
按照“单元测试的艺术”一书中的统计(以单测为例):即便额外增加了开发阶段的成本。考虑后期链路和迭代过程中的投入,整体上还是有效率的提升