大家好,我是冯张弛,来自 OPPO 商业能力中心 - 工程效能组。本文主要基于 OPPO 近年在落地持续交付时遇到的一些实际问题,阐述我们是如何利用代码快照技术与传统的代码覆盖率相结合,来定位与解决问题的。希望编译技术在能效领域的应用能给各位带来新的思考与启发。 在进入正文之前,我先介绍下 OPPO 落地持续交付的大致背景,与这个吸睛副标题“研发体系的最后 100 米”的由来。 持续交付(以正确的速度,做正确的事情,维持正确的质量)一直都是 DevOps 领域的热门话题,也是近年 OPPO 互联网在能效领域的一大目标。高频次的交付对质量团队是一个巨大的考验:如何在成本倍增的回归测试中维持原有的质量? 秉承着“无度量不改善”的原则,我们提出了不少诸如“可体验率”、“24h 内交付”等指标,辅以各类技术指标来拆分与牵引,希望从流程上引导业务团队。在取得一定效果的同时,我们也从指标中看出了一些问题: RD 与 QA 在迭代中的交互流程 我们发现,“提测 - 验证 - 打回” 的轮数随着交付频率的变高,成为了我们进一步提速的一大阻碍。为避免用户与平台方之间的认知偏差,我们深度走访了各个一线研发团队去了解其背后根源,可以归纳为三个主要原因: 我们可以用信息论来解构这三个矛盾点。比如,需求评审是产品向研发传递需求信息的过程;早会是信息广播的过程;编码是研发向机器传递指令的过程…… 同样的: 用信息传递的方式来描述这个过程的话: 无处不在的编解码
找到合适的介质将是解决这个问题的关键。而人总是倾向于解决容易解决、收益明确的问题,这类问题因研发环节错综复杂、过于主观、描述模糊等多种限制,往往被我们避而不谈,成为一个灰色地带。 图源:网络 这个深藏在研发流程中的灰色地带被我们称为 “最后一百米“。例如前几年非常流行的送餐机器人,厨师只需要将菜放到机器人上,但最后送餐到桌前时,依旧需要配置人工把餐端到桌上。对应到实际工作中:写了一堆提测文档,最后还是人工指导;写了一堆自动化,最后还是人工点检。这种薛定谔式的提效,就是本文接下来想要讨论与优化的。 刚才提及的三种介质中,相对来说代码是有明确规范、比较客观且可量化的一种。他是开发人员的思路编码,被其他开发人员与 QA 解码并使用。而我们希望将 QA 人员的思路与其相结合,来形成一种复合介质,代码覆盖率是个很自然的选择。 我们的实时染色系统 代码覆盖率并不是一个很新鲜的话题,业务也已经有了大量的实践经验,不再过度赘述。简言之,我们可以通过染色(抽象或具象)将 runtime 数据(也就是 QA 侧的行为),与代码绑定在一起呈现。 我们早期在覆盖率上花了不少功夫,总结为: 并在此之上建设了诸如实时染色、多版本聚合、用例绑定等流行的能力,并与流水线做了深度的融合。 深度融合研发流程 我们一度对此颇为满意,直到持续交付开始。 持续交付带来了海量的指标,用于把控整套流程的有序性。覆盖率作为一个合适的介质自然也不例外,我们希望业务去观测与优化。 第一个问题是,覆盖率与纠错率是正相关,但又不完全是。严格意义上他只能起到牵引的作用。 一个开源仓库覆盖情况 常见的开源项目都会以代码覆盖率作为一项关键的质量指标,用于反映整体的置信度。而在这种诉求下,质量反而不是用例需要首要关注的,这催生了不少作弊的乱象:不带断言的用例、无序遍历替代手写等。商业公司当然也不例外,我们在第一轮盘点中就发现了不少没有断言的用例。 机器相关的问题终归是有迹可循的,用例检查、复合指标的方案可以有效地将用例控制起来。而第二个问题则回到人身上,更加棘手。 某业务某次迭代的增量变更 即便将需求拆得更加小,我们的现实状况是,每两次发布之间依旧有动辄万行的增量变更。对于一个外包占比不低的团队,在这种情况下要进一步提速是很困难的:花在理解增量代码上的成本可能比全测一遍还高。在此基础上,业务并没有很强的意愿去做这个事情,尤其是在降本增效的背景下。 但实际上,我们的指标完成得不错,也确实带来了一些相关度量指标的改善,as usual。他对 “最后一百米” 的解决起到了一定作用,但在以人力为成本。 阶段成果与不同视角观感 额外的读码带来的成本是必然的,只不过它是否能被大家看到,不一定。这件事情本身很微妙:
当然,玩笑归玩笑,我们还是希望正视真正的问题,优化真正的成本,而不只是看起来的表象:中台能够不止让老板爽,要让整个团队都爽起来。 第一步当然是搞清楚用户画像与用人成本,这也是中台人员经常忽略的。关注这件事情最初其实是从云成本盘点开始的:当我开始察觉平时跟我打交道的机器们这么贵的时候,我开始注意到工作中跟我们打交道的人也并不便宜。为了评估团队人员结构的健康度,首先需要知道企业真正需要的是什么样的人。 不应被中台忽视的人力成本 DDD(领域驱动开发)理念中分化出了一个角色:领域专家,他很适合由 QA、项目经理、产品经理来扮演。他强调一个语义上的职责划分:
通过这种视角:
我们也可以从培训体系上配合,打一套组合拳,让团队结构更加合理化:
值得注意,正如我们对研发人员的两面要求一样,我们也希望 QA 人员能在关注业务逻辑的同时,至少应该看懂 DSL(domain-specific language,下同)级别的代码。所以我们并没有完全放弃对 QA 人员在能力上的培训。 看起来很美好,我们也希望通过这种方式让不同群体能够更加关注、精通属于自己的那部分工作,提升工作效率。 图源:网络 但这本身是个文化布道的问题,涉及文化的事情往往要比技术复杂得多:文化是个抽象的概念,他需要一套大家都能理解的共同语言作为载体来引导,诸如春联与春节,少林寺与中国功夫。一套好的文化需要有载体来建立认知与加深理解。他需要有足够好的可描述与可读性,使得对话双方都能在负载较低的情况下准确地互换信息。代码并不能做到这一点:领域专家需要做一轮解码才能得到领域逻辑,这个过程会有信息损耗。 那么,我们是否能用机器替代这层解码,使得大家通过代码感知到的业务模型都是一致的? 针对代码,我们可以有如下推论:
自然语言与代码的降噪前后对比 类比到自然语言的对应关系: 而实际上,编译器就是这么 work 的: 常见的词法与语法分析流程 那么,我们是否可以,像处理自然语言一样,从冗长的代码中自动抽离出简洁的 DSL 层,作为研发流程中的共同依据?这就是代码快照系统的由来。 支持多语言的标准格式化 我们通过静态解析,实现了一套多语言统一的、无编译依赖、秒级的代码快照系统。他能够针对不同语言进行不同维度的信息抽取与提炼(例如方法、类、模块等),为 DSL 层提供事实依据。 某仓库的文件依赖关系图(基于函数) 在提交维度上,我们也提供了文件、方法、类等各个维度的上下文推导,组词成句,使得词之间的关系都能够被链接到一起。 仓库中每个方法的“前世今生” 在仓库维度上,依靠高效的处理,我们能够为每一个原生代码仓库同步维持一个对等的快照仓库。结合仓库历史,我们有足够的信息可以知道,在每一个瞬间、每一个文件、每一行代码在逻辑层面上代表着什么,而不再需要(过多的) dive into code。 与仓库保持自动镜像同步 在体系维度上,我们希望他能提供一个相比原生仓库更加强大的只读层:
在上一个章节,我们希望通过快照系统作为底层根基,形成研发域内的 DSL。本章节将会展示我们在将其与研发体系绑定之后,一些在此之上孵化的解决方案。 回到刚才我们遇到的增量变更难以描述的问题。 引入需求影响面的前后对比 首先做的是结构化拆分,我们通过以下几个维度将迭代引起的变更拆细:
如此做之后,我们可以知悉整个迭代的影响规模,而规模是用规范的 DSL 来描述的,能够被工具、人进行进一步的处理。 其次是范围缩小,万级别代码对应到方法层也会有数以千计的方法量(如果算上上下游则更多),并没有带来本质上的缩减。为此我们开发了冷热方法标记系统,对方法权重进行标记。 冷热方法标记系统 分为五个维度: 通过加权计算,我们即可为所有方法进行权重分级,提供可视化供快速定位: 3 号方法权重高于其他 最后是覆盖率,既然是 DSL,我们当然希望他是支持双向消息传递的:开发侧信息能被固化为 DSL,那 QA 侧的执行信息也应该能被固化。覆盖率在原生存储结构上与仓库很接近,所以接入也非常方便: 快速定位漏测的 4 号方法 总结来说,对比原有的方案:
我们在前面提到了另一个问题,关于自动化用例的有效性不知道如何验证。实际上在质量侧关于用例有效性的讨论已经很多,阻碍我们的主要是开发成本。 工具耦合度前后对比 前面提到,质量侧的工具没有收到足够的信息做进一步的决策,这迫使工具方只能通过一些诡异的手段(如反编译制品、直接拉原始代码手撸解析等)补齐信息。而随着涉及编程语言种类、对接端增多,工具的兼容成本甚至经常高于功能本身的开发成本。 快照系统的 SDK 优化了工具侧的孵化成本。系统方提供了不同语言的 sdk,工具方可以统一从快照系统中捞取代码元信息,不再需要兼容多种语言,也不再苦恼于如何提取信息。 自动化用例管理 在大型企业中一直是个比较头疼的问题:
而在此基础上做一些全局配置与变更则更加痛苦:
因为用例也是代码,他们自然也会纳入快照管理。所以我们可以很方便地基于仓库维度将所有的用例进行中心化汇总、管理、检查。 流水线驱动,多维度 BI 展示 故障注入与发现能力是一项来源于变异测试与混沌工程的实践。他通过给应用注入一些故障,来反向校验用例发现故障的能力。他最大的阻碍有两个:
注入流程与规则分级 前文说到的冷热方法标记系统,使得我们对于仓库中的每个方法都会有优先级区分。在此基础上,我们设计了三个级别的通用故障规则,只要事先制定好各自规则所关注的方法域,平台可以在无感的情况下自动匹配对应注入点,将预设故障注入业务容器,该容器就可以用于验证用例。 与热门的 AI 驱动单测生成不同,我们更希望单测的出入参中带有业务语义,所以我们采用的是真实流量驱动生成的方式。 我们提供了 IDE 插件的形态供业务使用,大部分方法都可以随查随用,简化编写 MOCK、出入参的流程。 随查随用的 IDE 插件 而基于快照系统提供的元信息,生成器可以用类似的逻辑处理不同语言,将参数进行反序列化后回填为 DTO,生成不同框架的用例片段,开发人员可以直接复制粘贴使用。 用例有效性一般分为四个领域:
在编写效率上,我们也提供了单测辅助生成插件,用于尽可能缩短新需求自动化测试与研发进度的 GAP。 在用例有效性上的生态孵化是我们一开始没有想到的,其他维度上的建设也正在不断进行中。我们也乐于看到,随着开发门槛因为快照系统的出现而降低,有更多人能够不再被劝退在第一步,愿意参与到效能建设中。 从矛盾的维度,前文提到的三大主要矛盾在最后都得到了有效收敛: 从指标的维度,快照系统作为一项偏底层的能力,其相关收益可能较主观而不够准确,仅供参考。 场景较多,仅供参考 未来我们关注的方向主要有两个,分为能力与生态。 第一个是能力。无论在内部与外部的分享中,我们都会收到一些质疑的声音,这很正常。其中一个很大的点是,调用链这个概念并不新鲜,很多同学不认为它能承担如此大的角色定位。但调用链并不是一个单一概念,他是多元的: 而我们的目标是为海量仓库与海量 commit 建立 DSL,在效率、相关度上都有很高要求,所以在静态层入手更加合适。相对的,快照层的业务关联度最弱,因为实际的代码运行没有发生。 不同层级调用链的关系 在我们的规划中,他们是逐层叠加的关系。快照层开放了上报接口,支持从其他平台采集到的 RUNTIME 数据的导入,进一步补全 DSL 在业务域信息的不足。 第二个是生态。我们目前开放了多种语言的 sdk,供应用开发者、平台开发者在不同场景下接入使用,简化信息传递成本,与业务携手共建生态,良性生长。 不限领域,不设边界 除了提供单独开发的能力,快照也打通了仓库之间的边界,提供了全局逻辑关联的可能性。 GitOps 驱动的应用拓扑自动生成 例如跨业务微服务间的接口管理一直是个难题。通常我们会需要利用诸如 IDL 之类的标准化手段来管控接口信息,而这通常滞后且费力,因为规训人往往是最困难的。基于快照,我们可以轻易从不同仓库中抽取符合标准规则的接口 stub 以及 DTO 信息,在业务方无感的情况下形成大型的应用拓扑图。 与 DevOps 左环共生 放眼于研发体系,我们希望他能够真正意义上成为贯穿 DevOps 左环的核心组件,构筑 RD 环与 QA 环内高效有序的信息循环。 本文是一个传统编译技术在能效领域的应用。在目前的时间点来看,跨界的技术应用是一个不错的新技术产品的孵化方式。就事情本身来说,无论是横向(github)还是垂类(codecov)产品,通过静态代码分析抽取信息进而应用到研发流程,行业也在不断开展新的思考。 感谢前人做出的贡献,感谢开源。 因为内部版本不像 PPT 如此理想化,部分设计与业务系统耦合较深,短期暂无开源计划。感兴趣的同学可以关注下方非官方的开源版本与相关材料: 冯张弛,OPPO 商业能力中心工程效能组高级 DevOps 工程师。毕业于中山大学软件工程专业,2018 年加入 OPPO,服务于商业能力中心 - 互联网测试部 - 工程效能组,主攻编译流程、基础架构与 DevOps 流程方向的研究。在业务侧到平台侧均有丰富实操经历,视野全面。先后负责过小规模 DevOps 落地、类小程序质量保障、持续性能监控、编译流程改造与插件设计等工作。多年的国外开源项目 / 社区协作经验,深刻洞察主流研发流程中各个角色的不同需要与痛点。 今年 5 月 26 日至 27 日,QCon 全球软件开发大会即将落地广州,从下一代软件架构、研发效能提升、现代编程语言、AIGC、数据驱动业务、金融级分布式数据库、工业互联网、出海的思考、Web3.0 时代的金融系统、大前端架构等角度与你探讨,欢迎你来现场打卡交流~ |
|