闲鱼从2014年创立，到2022年已经走过了8个年头，闲鱼APP也随之逐渐复杂。在这其中，我们也面临着大型APP共性的一些通病，例如：团队规模变大带来的研发效能瓶颈的问题，大量历史代码带来的代码腐化问题等。从解决实际问题出发，闲鱼终端团队和质量团队一起协作在2022财年进行了CI能力体系化建设，并已经通过在单测，代码质量，自动化测试&回归等方面的建设，形成了一整套的能力沉淀。通过这些能力，我们成功在闲鱼终端研发场景下实现了代码质量的稳步的提升，并在部分仓库现了向类主干开发模式的切换。本文将分享整个能力建设的过程以及我们在其中的思考，希望能给大家带去一些借鉴。

千头万绪的开始

开始接到这个命题的时候，我们都陷入了轻度迷茫。因为项目一开始就遇到了不少挑战：

1. 1. 基础设施能力不足

首先从能力上说，集团的主要CI能力是围绕服务端和前端展开的，面向客户端的能力非常有限。这里不要说单测，简单的代码静态检查也是没有的。闲鱼之前也机会没有类似能力储备，一切都要从零开始。

1. 2. 项目执行成本高

虽然整个过程团队的TL层给与了很大的支持。但是作为一个技术项目，且涉及各团队的同学共同协作，在推进过程中总会被这样或者那样更重要的事情打断。整体项目执行层面的成本是高的。

1. 3. 固有观念的阻碍

如果其他的问题都可以通过“勤奋”来克服。但是很多同学心目中的“单测无用论”，“自动化是KPI”，“又不是不能用，等出问题再说”等观念已经根深蒂固，这是项目组要面临的更大的挑战。我们非常担心大家在执行过程中是一种机械式配合，而不是真心认同。如果还要消耗个人情谊，做“纯友情支持”，就更加不是我们想要看到的。

仰望星空，脚踏实地

当然困难虽然多，事是要干的。通过跟大家的沟通，其实CI能力不好覆盖，最为核心的阻力还是“成本”。做CI体系建设，就不可避免的要建立各种自动化测试的能力。所以动手之前，还是得先好好算一算账。到底自动化测试（包括单测和UI自动化）的成本高还是低？

确定性收益：

做个简单的归纳，核心收益来自于：

1. 1. 问题发现的前置。这里不仅仅反应在问题解决效率上，更加体现在真金白银的花费上：

一方面是：越往后发现问题往往需要越多重复性的回归测试投入（如下图所示） 另一方面是：越往后往往意味着越多的协同。如果到了临近发版再出问题，那可能就需要开发，测试甚至业务同学一起协作解决了。这样的成本也会大幅提升。

1. 2. 规模化验证下的巨大效率提升

从功能数量和回归次数两个角度，可以清晰对比出自动化测试在规模化以后的巨大效率提升。【《持续交付 2.0》】

1. 3. 其他优势

机器相比于手工回归，具备随时随地回归的特性。开发同学能从中获得极具幸福感的开发体验：快速反馈，快速迭代。同时为了提升CI覆盖的效率，开发往往会被倒逼进行更好的接口设计，架构优化。代码结构往往更好。

此外机器回归还具备结果稳定性高，拓展测试的深度和范围（能尽可能发现底层问题），覆盖纯手工无法覆盖的场景等等的优势。

直面成本：

首先必须承认自动化能力（包括单测和UI自动化等）的开发，需要投入更多成本。这里包括一次性的成本和后期迭代的外投入的成本。 

按照“单元测试的艺术”一书中的统计（以单测为例）：即便额外增加了开发阶段的成本。考虑后期链路和迭代过程中的投入，整体上还是有效率的提升，并且最终交付的质量也大幅得到提升。

基于这里的数据，我们可以得到一个结论： CI的提效的本质是将未来部分不确定性成本（回归，修复bug）部分转成开发阶段的确定性成本（单测和自动化能力开发成本）。从而获取整体研发周期内的效率提升。

从实际出发，闲鱼的情况会更加艰难，特别是在互联网公司的极快的迭代速度背景之下。如果开发时间都很紧，进行CI覆盖就更难了。所以推动CI体系的建设，在不改变现有研发模式情况之下，核心还是要解决成本的问题。而这也是闲鱼CI体系建设过程中贯穿始终的考量点。我们会在覆盖和使用两个维度进行成本控制。

新机会

那么此时此刻来做这件事，是否有进一步提效的可能？从闲鱼视角，我们有一些独特的机会点：

1. 1. Flutter技术栈带来的新机会

众所周知，闲鱼应用是以Flutter为主的技术栈。新的技术栈除了在开发阶段给团队带来的效率提升，在自动化测试部分同样带来了新的改变 。相信大家可能都看过下面这张图【单元测试的艺术】：

这里核心有一个核心判断： UI测试要比单元测试成本高很多。但是Flutter环境下，透过Widget test能力，我们能在不构建APP，且不使用真机的情况下，完成UI的自动化测试。对比如下：

场景	真机	Flutter Widget test
获取耗时	35 min	5s内

备注：由于mock数据和屏幕尺寸的差别，显示上会有部分差别。 可以看到我们获得者两张渲染图的成本有着巨大差异。Flutter通过跨平台渲染的能力，可以在纯代码测试阶段实现类真机场景的渲染，从而大幅提升UI自动化测试的效率。这是传统场景下暂时无法做到的。实际场景中数据：以Kun工程为例 1152个测试（绝大部分是UI相关单测）用例可以在5min内跑完，这个效率相比传统方式已经有了质的提升。 此外由于没有包构建和真机环境的干扰，Flutter 单测的执行稳定性也远高于传统UI自动化。

1. 2. 自定义Devops飞鱼带来的新机遇

如果说Flutter单测能力的突破解决的是Flutter CI覆盖成本的问题。那么在使用侧，我们需要借助飞鱼来降低规模化落地以后的使用成本问题。 

透过自定义研发流水线，我们获得了更加丰富的流程管理能力。基于飞鱼平台，我们将CI的能力与研发管线充分绑定。一方面可以自动化利用CI做问题扫描，并通过反馈机制实时将发现的问题反馈给对应开发同学。另一方面，也能做到在研发流水线的关键位置的做卡口，避免破窗效应的产生。

合理的目标

设定一个合理的目标，是项目成功的关键。作为CI建设元年，我们透过核心业务和技术场景的覆盖，完善基建，跑顺流程。同时我们将项目的重点放在团队同学对CI观念的重塑上，逐步推进团队成员形成CI应用的自驱力。 基于此，我们明确了几个原则：

1. 1. 可落地 不依赖行政手段硬推。跟具体场景结合，真实解决实际项目中的问题。考虑不同业务，不同场景的情况，因地制宜设定目标。

2. 2. 可维护 通过机制保障建设成果不退坡，避免重复建设。

3. 3. 可持续 不过分关注覆盖场景的多少，重点看真实产生的效率收益。

   撸起袖子干

   整体建设围绕两个主题展开： 一个是：基础能力设施的建设； 一个是：代码仓库的CI能力覆盖。

能力建设

能力建设的目标是尽可能降低CI在使用侧的成本。通过基建自动化利用CI能力，暴露代码质量问题。

自建jenkins集群

为了统一承接各个场景对CI运行时的需求，我们自建了一个jenkins集群。除了jenkins自带的任务调度，日志等能力之外，结合闲鱼的场景，我们重点在如下方向进行了能力增强。

1.满足对不同环境的述求

Mac环境：适用无法在Linux环境下完成CI执行的场景。例如闲鱼不分工程中使用了goldenFile的方式进行单测覆盖，但是mac和linux对同一字体的渲染有细微的差别，导致结果图的校验失败。为了避免保存多套单测结果，该仓库的单测会绑定Mac环境运行。 

此外，除了通用的Linux环境，自定义集群具备定向算力拓展的能力。例如Quark（模拟灰度）任务要做大数据量的回放测试，需要消耗很多机器资源。我们针对该场景单独划拨机器进行支持。 

2.充分利用自有环境对CI运行进行加速 考虑到端侧环境的复杂性。我们在自定义集群中对机器环境进行了定制，以提升CI执行速度。例如：内置闲鱼的Flutter版本，无需执行doctor即可直接使用。再者，机器中针对下载依赖，做了统一缓存。这样能避免每次CI执行的的时候反复下载，从而大幅提升CI执行速度。

UI 自动化

除了现有的代码级别的单测能力，我们还建设了基于APP的UI自动化测试能力。这是因为：UI自动化能对纯代码单测无覆盖的场景进行补充。例如埋点功能的验证和性能测试等。 我们基于蚂蚁集团的真机试验平台，建设了闲鱼专有的能力。目前可以覆盖的场景包括：

1. 1. 主干功能回归

2. 2. 核心页面的性能采集和对比

3. 3. 核心埋点自动化验证

4. 4. 核心场景自动化验证（例如特定场景容器UI组件的UI自动化测试）

   飞鱼&CLI工具链深度整合

   飞鱼是闲鱼CI的核心基建，具备如下功能：

5. 5. 对基础CI 运行时的能力封装，将集群能力对接到不同的场景中。这里的封装包括对不同CI任务的配置能力，以及CI结果的实时反馈能力等。

6. 6. 定义应用开发流水线，并将CI能力融入其中。飞鱼在应用流水线中几乎任何节点都具备CI触发和卡口的能力，真正做到让CI发挥出应有的生产力。

7. 7. 对所有的CI进行数字化采集和统计（细节可见下图），方便对CI运行情况做实时监控。及时对异常CI任务做风险提示，提升CI任务运维效率。

本地研发CLI工具链通过跟飞鱼打通，能在本地开发阶段灵活触发CI任务，并实时获取结果反馈。这极大提升了开发同学在日常开发过程中，运行CI的效率。

融入代码平台打通CR

CR是研发过程中一个的核心节点，也是代码合并的最后一关。是否在CR过程中发现足够多的潜在问题，对代码质量的影响举足轻重。本财年，闲鱼在CR侧，做了大量规范化动作。首先明确，向主干分支合并代码必须经过CR。CR过程需要至少两人的同意，且CR过程的问题需要全部解决以后，代码才能合并。我们也针对CR过程的核心问题进行专门记录，其中具备代表性的问题会在团队周会上统一分享。如果早期的CR看得多的是命名和格式问题，现在越来越多的CR已经能洞察更深层次问题：临时方案会被卡，核心能力没有单测覆盖会被卡，接口抽象不一致同样会被卡。在CR上的坚持，我们不仅收获了代码质量的提升，同时团队也形成了对代码精益求精的编码氛围。

除了依靠人的经验，CI和CR的整合在闲鱼场景中形成了1+1>2的效果。从提交者来说，CI通过代表代码核心逻辑正确，能增强提交者对代码质量的信心。同时CI对进行Review的同学来说同样重要。一方面如果CI都不通过，CR也就无需进行。另一方面如果CI通过，就不用重复Review CI已经保证的问题，提升CR效率（这里最为明显的是代码风格和命名的问题，目前基本上通过lint检查进行基础保障）。 

我们围绕代码平台重点建设了两个能力： 一个是基于Flutter的单测能力，一个是基于Flutter的静态代码扫描能力。

Flutter单测	Flutter Lint

并且通过设置卡口来持续保持CI执行质量：（任何一个任务失败都会导致无法合并代码）

场景覆盖

覆盖策略

如果说基础能力建设是一个确定性问题。那么业务覆盖就需要千人千面的对待。CI进行场景覆盖的时候，考虑成本和收益，我们有着清晰的取舍：

1. 1. 发现效率优先

首先高质量单测具备两个特点：一个是快速发现问题，另一个是快速定位问题。如果发现效率和解决效率出现了冲突，可以选择发现效率优先。如下两个例子做出清晰解释：

boder-color 属性单测	我发布页面单测

左边是针对boder-color这个属性就行单测覆盖，右边是对一个业务页面进行整体单测覆盖。如果同时出现问题，左边的问题定位的速度会大幅高于右侧。但是从覆盖效率上来说，右侧一个用例覆盖的case要比左侧多得多。覆盖相同的属性，右侧的效率也明显会更高一些。虽说右侧有些取巧，但是我们仍然欢迎。因为从工程实践中出发：知道有问题远比问题解决更重要。遵循这一原则也是基于成本和效率平衡的考量。

1. 2. 代码分层覆盖

尊重历史包袱的现实，不搞一刀切。我们鼓励业务线同学，对代码进行分层覆盖。建议从基础到上层，从核心到边缘，从新增到存量，渐进式推进CI能力建设。

1. 3. 单测覆盖优先

实践过程中单测相比UI自动化从执行效率，到结果的稳定性，到验证成功率都有着量级优势，是理想的CI覆盖能力，所以会优先选择。UI自动化做场景补充：例如性能测试等。这样各取所长，能最大化提升整体CI覆盖效率。

覆盖效果

在明确了原则以后，我们分不同的场景来介绍具体的覆盖效果： 核心客户端技术仓库 闲鱼有8个核心Flutter仓库完成了Flutter单测的覆盖。其中闲鱼的图片库，大前端容器，富文本，滚动容器等仓库的行覆盖达到80%

核心客户端业务仓库 考虑到业务仓库历史债务比较重，所以这里采用渐进式方式进行覆盖。我们挑选高优先级P0测试用例进行优先覆盖。除了单测行覆盖之外，还增加了P0测试用例覆盖率的指标进行辅助评估。其中详情，搜索，发布和交易四个核心业务进行的单测覆盖，其中详情页的P0测试用例覆盖达到80%+。

核心前端组件覆盖 闲鱼内部通用跨平台组件库js侧的代码也进行了单测覆盖。组件库中的80%的组件的行覆盖超过了80%。

开花结果

完成基础CI覆盖以后，我们在多场景中收获了效率提升。

亮剑腐化代码

曾几何时，面对腐化代码，大家是不是都有过一种“有心杀敌，无力回天”的感觉。这里面的心酸可能来自于历史债务累积过重难以梳理，也可能来自于资源问题难以立项。但是当你的仓库有CI覆盖以后，一切就变得简单了。

以闲鱼Flutter仓库迁移Null Safety为例，由于闲鱼Flutter技术栈使用比较久，历史包袱比较重。迁移过程中有CI覆盖的仓库迁移速度明显更快。以闲鱼富文本仓库迁移为例。由于有近80%行覆盖单测的保障，我们仅仅使用4个小时就完成的整个仓库的迁移，并且集成以后几乎没有什么大问题。整个过程没有测试介入，纯开发完成。而大量没有CI保障的仓库还在等待资源排期。 

透过CI能力的保障，团队同学对腐化代码可以做出更及时的反应，看到的各种问题也能在更小的周期内被清理。在终端融合的背景下，即便是跨栈代码的修改，主要有CI能力的保障，也会更有底气。

创意模拟灰度

在业务场景覆盖的过程中，我们尝试不同的方式来提升问题发现的效率。针对闲鱼宝贝详情以展示为主的场景，我们从线上接口流量中采集部分数据，对宝贝详情页进行流量回放。详情页利用已有单测用例对回放结果进行校验。这样就可以达到模拟灰度的效果。这么做本质上是利用线上流量来丰富测试场景的多样性，从而降低测试数据构造的成本。在这其中，我们不仅仅发现了详情页本身的问题，也发现了线上服务端数据的bug。

迈入类主干开发

主干开发作为更加敏捷的研发模式分支模型更加简洁。但是需要有可靠的CI/CD 基础设施。同时也要求开发者有很强的架构设计和特性拆分能力 。 

类主干模式是分支开发模式向主干开发模式迁移的一种中间状态。整体上类主干开发模式相比于多分支开发模式最大区别点是分支开发结束以后，一旦CI测试通过并且完成CR即可合并回主干，不需要人工干预。类主干开发模式开发周期逼近主干开发模式，在发布侧可以做到随时发布。 

闲鱼通过在CI/CD能力上的持续建设，我们已经顺利将闲鱼的Kun 和Mural两个仓库顺利迁移到类主干开发模式。 透过主干开发模式，我们收获了惊人的效率提升。以大前端容器Kun工程的仓库为例： 在过去的12月，仅仅一个月的时间内，项目组同学（客户端和前端）在代码库中提交了 400+次，新增近10W行代码， 删除近13W代码。这么大量的提交，核心依靠的是1152个测试用例以及配套的UI自动化用例共同保障的。效率提升可见一斑

星星之火

基于CI能力的不断建设，我们欣喜的看到：应用CI到自己场景的同学越来越多了，针对腐化代码的改造越来越快了，跨技术栈的修改越来越频繁了。虽然从大盘出发，今天的CI覆盖面依然没有那么广。但是值得庆幸的是：团队同学对CI的观念却发生了翻天覆地的变化。在完善CI覆盖的仓库中，极速的CI结果反馈，极快的高质量迭代，开发同学哪怕只体验过一次，就真的再也回不去了。 

最近一次偶然的线上问题Review，猛然听到大家提的第一个问题是：为什么CI没有覆盖到？而不是之前的：为什么测试没有回归到？我的内心掠过一丝波澜，因为我知道迈向卓越的星星之火已经点燃，期待“燎原”之日~

引用

1. 1. 《单元测试的艺术》

2. 2. 《持续交付 2.0》