百度 APP 移动研发平台及 DevOps 实践

2021 年 11 月 12 日
本文字数：6242 字
阅读完需：约 20 分钟

1. 概述

百度 APP 从 2018 年开始，团队规模和业务规模都迎来了巨大的增长，也带来了研发效率、组件复用、APP 性能等多个目标的挑战，于是驱使我们做了很多组件化的工作。随着百度 APP 组件化程度的提高，组件逐步拆解到各个独立仓库，组件真正做到了逻辑、资源各有归属，主工程也实现了完全壳化，于是我们开始建设工具链（MGIT、EasyBox）来规范组件管理与使用并提升编译速度。工具链更多承担的是开发环境的配置，提升的是研发同学在开发阶段的效率，但面临整体移动研发流程琐碎，多仓库环境下的持续集成困难，组件质量难以保障等问题，我们仅仅依靠工具链是不够的，于是 Tekes 应运而生。

2. 百度 APP 移动研发平台—Tekes

Tekes 是服务百度移动研发的一站式服务平台，目前主要包括三个大的功能：

自动化研发流程，如自动发布、准入，SDK 自动准入，并在研发流程中增加约束，保障效率、复用、质量、性能、安全等目标；
组件和 APP 的防控劣化，如组件复用输出能力、整体质量、影响用户留存的启动速度、体积等因素；
全局知识库，如文档中心、服务号、客服系统、考试系统等。

Tekes 的名称起源于新疆的特克斯县（Tekes County）。特克斯县因八卦布局而闻名，是国内唯一没有红绿灯的城市，城内路路相通、街街相连，传说从来不堵车。我们借此寓意，目标提升超级 App 及孵化产品全流程研发效率。

目前 Tekes 管理着包括百度 APP 在内的 6 条产品线，Android 及 iOS 双端超过 800+个仓库，1500+个组件，平均每天触发自动化研发流程相关的流水线 200+次。

接入 Tekes 后，移动端开发同学不仅可以通过自动化研发流程大幅缩短开发时间，还可以通过研发各阶段流水线产出的质量报告、前端页面展示的产品线和组件的防控劣化数据来改进开发流程，提升质量意识。

Tekes 同时也贯彻了 DevOps 的理念，建立了一个全局知识库、沉淀研发过程中的文档，要求开发同学学习研发流程规范并通过相关考试，并且 Tekes 团队的同学也在持续识别和改善约束点，所有人教学相长，最终实现共同的目标。

3.Tekes 的架构演进

百度 APP 不同发展阶段有着不同的目标，但始终对研发效率有着刚性需求，Tekes 也在不断强化自身的架构来支撑研发全流程高速运转，并逐步发展为现在的『百度移动研发的一站式服务平台』。发展阶段如下图所示：

下面我们详细介绍各个阶段下 Tekes 的架构。

丨第一阶段：自动化

Tekes 一开始是作为组件二进制自动发布准入的调度后台服务，这是一套基于代码组合入（Topic Merge）和流水线持续集成（CI）的自动化流程。

组合入是将一组(一个或多个)仓库的代码同时进行合入操作。由于百度 APP 的客户端代码是多仓库的，开发者在开发过程中不可避免地需要同时修改多个组件，此时由于代码入库的时机不同，导致入库中间过程中持续集成触发打包会常常发生错误，因此我们引入组合入的概念。

组合入基于 Gerrit 的 Topic 机制，即把一组 changes 通过同一个 topic 归集到一起

当 Tekes 收到代码组合入通知时，会主动触发一条百度 APP 持续集成流水线，称为『发布流水线』，这条流水线会使用 EasyBox 等工具构建百度 APP 工程、编译有代码修改的组件并发布到组件的二进制仓库。整个过程称为『发布流程』。

Tekes 收到组件发布完成的通知后，会自动修改主工程的配置文件，将 APP 引用组件的版本自增。整个过程称为『准入流程』。

主工程，即所谓的“壳工程”，顾名思义就是客户端工程分离业务代码，仅仅保留一些工程配置选项和组件描述文件得到的”空壳”。构建完整的 APP 工程时，会将业务代码以组件的形式集成进来的。

这个阶段，Tekes 的角色是一个调度者和连接者，本身没有什么架构可言。通过调度 CI 流水线，连接 EasyBox 工具链和百度 APP，实现了在研发流程集成测试阶段将组件从源码形态自动发布为二进制形态，并实现自动化准入。

组件二进制自动发布准入将每个开发人员的上车耗时从小时级别降低到分钟级别，不仅节约了宝贵的时间，还有效地降低了版本迭代 delay 的风险。

丨第二阶段：平台化

2019 年百度 APP 中台化如火如荼，随着中台化的工作不断推进，不仅需要有业务中台提供成熟的组件支持快速组装 APP，还需要技术中台来赋能 APP 自动化能力，提高流程运转效率，保障业务的连续性。

Tekes 作为技术中台的核心能力之一，也在积极探索如何升级移动端研发模式，具体工作概括成”三板斧”。

第一板斧——自动化流程建设

完善自动化研发流程，分为横向和纵向两部分工作。横向上，扩展更多自动化流程来替代以前手动或者半手动的流水线工作，例如打包、单测、体积检查、infer 等；纵向上，在已有的流水线上增加更多的规范化约束，例如发布流程的版本号规范检查、接口/依赖的劣化审核等，准入流程的 APP 体积控制等。

第二板斧——移动组件管理平台搭建

从 Tekes 独立出了一个”移动组件管理平台”来专门管理可复用的组件为中台化服务，完成整个组件（及 SDK）发布及准入的闭环，如下图所示：

移动组件管理平台负责展示组件的数据（详情、组件化信息及质量报告），它的数据来源于 Tekes 的组件自动发布、组件手动发布或者 SDK/开源库组件的手动上传，产品线的中台负责人可以通过页面交互触发 Tekes 的组件自动准入将指定组件的指定版本准入到 APP 中。

第三板斧——多产品线输出

上游和”APP 中心”（百度内部的 APP 开发平台）互通，下游和矩阵产品团队进行接洽和工程改造。矩阵产品通过接入 Tekes 的自动化流程和组件防控劣化，解决其手动发布组件成本高，源码仓库编译效率低，组件的质量难以控制等问题。

这一部分属于应对不同产品线研发模式升级的实践，本篇文章不多做介绍。

架构

这个阶段对 Tekes 进行了平台化的升级，明确了 Tekes 的三大服务——流程、组件和产品线，整个架构如下图所示：

分层介绍我会放在下个阶段一起讲。

丨第三阶段：移动 DevOps

2021 年伊始，DevOps 作为软件开发领域热门的概念之一，并已成为敏捷软件文化的一部分。为了更好地提升百度 APP 及矩阵产品的工程能力和研发效率，实现”快速交付价值，灵活响应变化”。Tekes 也结合自身的现状积极探索移动 DevOps。

DevOps 是人员、流程和技术的联合，以不断向客户提供价值为目标，使以前孤立的角色（开发、IT 运营、质量工程和安全）可以协调和协作，以生产更好、更可靠的产品。——Azure DevOps

DevOps 在不同组织的实施上天差地别，对于 Tekes 来说，移动端的自动化流程及持续集成已经建设的相对成熟，我们进一步实施 DevOps 的模式，首先需要整合百度移动研发流程，识别并建立价值流。

在研发流程中，价值流可以定义为从需求提出到最终转化成产品，交付价值给用户的过程。

百度的研发流程，大致可以分为需求、开发、测试、集成和交付五个阶段，我们以此建立从左到右平滑的价值流，并梳理了每个阶段的主要活动，这些主要活动有些是手动的，有些是自动的（依赖我们建设好的 CI/CD 流水线），如下图所示：

然后，我们做了很多可视化工作管理价值流。因为在价值流中很多问题隐藏在那些看起来习以为常的活动中，对于像百度 APP 这样已经服务了多年的产品，背负大量的技术债务，问题隐藏的更深。可视化可以帮助识别并解决价值流中的约束点，避免问题传递到下一个阶段。同时，还可以优化研发同学的体验，能够清晰看到流水线每一个约束点执行的状态和产物等。

最后，在部门内同步 DevOps 认知和目标，发扬乐于协作积极沟通的文化，不拘泥于优化局部指标，而是把局部经验转化成全局经验，建立起全局知识库。

架构

移动 DevOps 是 Tekes 当前所处的阶段，还在不断改善中，架构如下图所示：

分层介绍

Web
Tekes 平台：移动研发平台，面向移动研发团队的 PMO、开发、测试、运维人员
移动组件管理平台：管理可复用组件信息，面向产品线的中台负责人
网关：统一 API 网关服务，反向代理、负载均衡和限流
应用服务：
DevOps 服务：管理全研发阶段的自动化研发流程，提供可视化服务
产品线服务：管理产品线数据；针对具体产品线还有一些客制化服务；
组件服务：管理组件数据；提供组件复用、发版和劣化防控服务。
运维监控：业务服务的监控（流量、请求、错误等），预警异常
基础服务：封装的公共基础服务能力，例如访问控制、流程控制、消息通知等
上游服务：依赖其他平台提供的服务，例如 UUAP、iCode、iCafe、iPipe 等
百度云服务：容器云平台，提供必要的基础设施和中间件，例如数据库、消息队列、对象存储等
全局知识库：除了平台功能之外，服务号、文档中心及相关系统，帮助提升移动研发团队工程能力，构建更优秀的 APP

相较于上个阶段的架构，这个阶段最显著变化是将流程服务升级成 DevOps 服务并建设了全局知识库，具体工作我们已经介绍过了。然而我们的工作不止于此，随着 Tekes 平台的壮大，越来越多的产品线接入到了 Tekes 中，我们一方面重构了 Tekes 后端服务的架构，拆分微服务，积极拥抱云原生来提升整体的扩展性和稳定性，更好地为多产品线服务；另一方面，我们也尝试把 Tekes 在百度 APP 的 DevOps 实践转化成经验并落地到其他产品线上，这是一个长期探索的过程，我们需要看的更远。

4. Tekes DevOps 实现原理

DevOps 服务是 Tekes 最核心服务，具体的功能包括：

管理发布流程、提测流程等业务流程，对外提供可视化服务
触发 CI/CD 流水线，接收来自流水线的消息通知
通用的工作流服务，负责流程的启动、推进和停止

丨业务流程

业务流程需要编排自身的流程定义，流程定义是一种描述流程图的 DSL，我们有一套自己的流程定义的语法，解释起来会比较麻烦，所以我们直接用流程图代替，例如：

业务流程将流程定义注册给工作流服务，工作流服务管理了所有流程实例的生命周期，业务流程不用关心具体流程是如何执行和调度的，只需要在监听方法里面写自己的业务逻辑，实现了业务与流程之间的解耦。

丨 CI/CD 服务

CI/CD 服务接收来自流水线的消息，并将其包装成”事件”，”事件”经过”过滤器”过滤后最终传递给工作流服务进行处理。

事件

流水线通过事件和工作流服务建立联系。事件有三种类型，都直接或间接来自于流水线的通知，如下图：

基础事件，来自于特定流水线请求
变更事件（Change Event)。仓库代码 change 合入前流水线（Change 流水线）的消息，包含一些基本的变更信息；
合入事件（Merge Event）。仓库代码 change 合入后流水线的消息，除了一些基本的变更信息外，还有评审人合入人的信息；
基础扩展事件，目前的扩展事件都是经过合入事件特殊处理而来的。各个基础扩展事件彼此独立，但是和合入事件并存
新提交事件（NewCommit Event）。来自仓库拉出新分支第一次提交的消息。因为这种提交会跳过评审直接合入，所以单独处理；
组合入事件（TopicMerge Event）。同一个 topic 下的仓库 change 全部合入后的消息，包含一个或多个合入事件。组合入事件是启动提测/发布流程的事件源；
Tekes 合入事件（TekesMerge Event）。Tekes 自动流程生成的 change（通常是自动准入）合入后的消息。因为这种提交会触发 Tekes 的自动评审和合入，所以也单独处理。
自定义事件，这是最多的事件，当 CI 流水线执行一个业务流程时，完成每一项任务（例如组件化检查）都会请求一次 Tekes，会生成对应的事件，可以说自定义事件是推进流程的事件源。

过滤器

CI/CD 服务处理事件时会有若干个过滤器，这里的过滤器基于责任链模式串联起来，形成一条过滤链。事件在链上传递，每一个过滤器都有机会处理该事件，并在处理后选择拦截或继续传递。

责任链模式在面向对象程式设计里是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

我们介绍事件时说到组合入事件是启动提测/发布流程的事件源，我们就以他为例，介绍一下他连接的过滤器：

TekesIgnoreFilter: 判断 Tekes 是否处理这个事件，例如 Tekes 关闭了自身 DevOps 服务或者此次提交的 change 信息命中了 Ignore 的逻辑（例如仓库、提交人，commit log 关键字）；
TopicMergeValidator：校验组合入是否有效，因为获取组合入的信息需要依赖上游服务（iCode），我们会在这里重新请求一次确保当前 topic 下的所有提交都已合入并能和 TopicMerge Event 包含的所有 Merge Event 一一对应；
MatchAppJudge: 裁决 TopicMerge 匹配的产品线（实际上是产品线的主工程），如果裁决不出来则返回失败。因为 TopicMerge 只有一组仓库合入的信息，没有产品线的信息，而后续如果触发流程，需要基于一个产品线的主工程去构建、编译及打包。由于存在多个产品线复用组件（仓库）的情况，我们裁决产品线有一套比较复杂的判断逻辑，这里也不做详细介绍。

使用过滤器处理事件有几个好处：

解耦。请求者（流水线）将事件传递给责任链后，不用关心具体的处理者；
灵活。允许动态地组合过滤器，形成新的责任链实现不同的功能；
优雅。每个过滤器只负责处理自己的部分，符合开闭原则。

丨工作流服务

在介绍工作流服务前，我们先介绍”工作流”，根据维基百科定义：

工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表达并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

工作流引擎是驱动工作流的工程实现，负责解释流程定义、管理流程数据、控制流程运行，并和业务解耦。我们的工作流服务就是对工作流引擎的封装。

工作流服务有四个模块：