随着移动互联网的快速发展，各大厂都拥有自己的超级 APP，为了尽快的满足用户需求，研发同学需要在这些超级 APP 上快速完成功能迭代的同时，还要保证质量。以抖音举例，上百名来自不同部门的研发同学每周都会向抖音工程中集成各自的功能（支付、feed 流、电商等），为了解决整个研发过程中的问题，字节内部自研了一套叫 Bits 的 Mobile DevOps 系统，用于支撑字节内部所有 APP 的 CI/CD 流程，保障了抖音、头条等头部 APP 的单周版本迭代。

本文整理自QCon 2022 北京站上李腾飞的演讲《字节跳动 Mobile DevOps 工程实践》，主要给大家介绍 Bits 系统从 0 到 1 过程中的一些工程经验和想法，通过 MR （Merge Request，合并请求）从创建到合入的过程展现整个研发流程的细节和功能。

背景

我于 19 年加入字节，一直在 DevOps 这一领域工作。今天很高兴能与大家分享我们的工作。自 17 年开始，字节内部着手从零开始开展 Mobile DevOps，本次演讲分享该平台在公司内部的使用情况。本次分享分为三个部分：

下图是当时项目当时的现状。

这个项目的背景是在字节内部 APP 快速发展的情况下，面临业务高速发展的挑战。在新项目立项时，无法从工程架构等方面充分准备，导致代码冗余问题，例如西瓜视频直接从头条仓库复制代码，使得头条出现 bug 后，西瓜视频也需要再次解决。此外，不同 APP 内的组件耦合问题也会造成安全和性能方面的困扰。为此，字节围绕组件化做了很多工作，使得在写业务时变得更加轻松。

问题

字节 Mobile DevOps 项目面临以下具体问题。

整理流程

当时在 2017 年和 2018 年，我们做了一个简单的设想来应对具体的问题。我们对公司内部的研发流程进行了梳理，无论是哪一端，我们都是从本地进行开发。业务通过组件化的形式，通过多个仓库进行代码隔离，从而实现部门与部门之间的协作和功能与功能之间的集成。最终，通过合并代码到主仓库的主干分支上，并通过集成区对外发布。

我们的核心思想是先建立一个组件平台，通过组件平台解决前期开发过程中的耦合问题，从而让整个研发流程的入口更加清晰。第二步是规范合并代码的步骤，包括如何合并多个仓库的代码并进行测试，以及如何将代码合并到主干分支上。第三步是建立集成区，将合并的代码对应到相应的版本上，并对外发布。下图我们整体的路线图和预期的方式。

组件平台

首先，我们需要关注解决的问题是平台的组建，为此梳理出了四个主要目标。

架构

为了实现这个目标，我们设计了一个单的组件平台应用架构。我们希望在底层屏蔽 CocoaPods 和 Maven 这些工具的复杂性，使用户只需要关注两种使用场景：组件的维护和组件的使用。我们还将平台上的用户抽象为这两个角色，以便为平台的维护方和组件方提供不同的流程和功能支持。

能力

我们基于之前的设计，实现了以下组件平台的能力。

下图是我们实际落地的组件平台。其中有一个 APP 统计的功能，比如 DBWebImage 这个库是我们公司内部的通用 iOS 网络库，该库的作者现在也在字节，他对开源版本做了适配并放到了我们的内网，成为了字节内部所有 iOS 通用基础网络库。APP 统计功能可以展示该库目前被哪些字节 APP 使用过。另外，我们还有依赖组件的功能，但由于这里采用的是单仓多组件的概念，所以这个功能并未被使用，不会在组件平台上展示。这就是目前组件平台的标准概貌。右侧的信息栏会展示该组件被哪些 APP 使用，点击进去可以查看这些 APP 使用的具体版本。

研发流程

问题

我们在解决了组件平台的整体问题之后，就可以将公司内部所有客户端的研发流程定义成一个多仓的方式。但是，在实际操作中，我们遇到了以下一些问题。

目标

鉴于上述问题，我们思考了一种方案：是否能够通过一个或多个流程或方案，统一处理所有业务场景。

原子能力

经过我们对这个问题的梳理，我们将所有流程中最关键、最常用的功能整理如下。

整体架构

针对研发流程设计的产品，我们重点介绍应用架构设计的两个方面：流程引擎和 Pipeline 引擎。

另外，我们也重点建设了数仓，目的是为了衡量平台的质量和为业务提供的价值和效率，使整个研发流程的各个环节和链路都能被可观测。值得一提的是，数仓建设是我们 21 年和 22 年的重点项目之一，从无序开始经过两年的努力，我们已经将整个研发流程变得有序。现在我们的重点是衡量平台质量，以及为业务提供的价值和效率，确保整个环节和链路的可观测性。

流程引擎

下图展示了我们的流程引擎。其中有以下四个核心功能。

下图展示了流程引擎的设计，用户可以通过拖拽中间的节点来自定义研发流程的顺序和功能。类似于 OA 系统的编排思路，用户可以设定某一节点完成后应该执行的下一个节点。虽然 Pipeline 没有回滚的概念，但是流程引擎具备回滚功能，这一点在后续会有详细介绍。

下图展示了流程引擎在业务中的应用。流程引擎包含多个阶段，其中针对安卓场景，我们会拉出一个影子分支来解决某些任务需要将源代码分支和目标代码分支合并的问题。这个影子分支在流程结束之前不能被合并。流程的下一步是运行 CI Check，包括一些安全和合规的检查，以及 Pipeline。然后进行 Code Review 和 Feature Check，确保合入代码与需求相关且符合安全合规要求。针对 Lock 的问题，我们解决了多个仓库合并的原子性问题。最后，当组件通过验证并成功发版后，就可以继续进行后续的流程，并成功合入代码。

流程引擎与 Pipeline 的区别，可以回归到我们所编排的阶段。如上所述，Shadow branch、CI Check、Code Review 等都是我们所定义的阶段，流程引擎的主要作用就是控制这些阶段之间的回滚、前进和跳过等操作。而 Pipeline 的主要作用则是作为标准化的服务，执行我们所定义的一系列操作。

下面这张图展示了 Pipeline 的编排，这是由纯业务自己去实现的，可以实现关联关系和顺序执行等功能。

在整个流程建设完成之后，我们发现 Pipeline 是一个需要解决的重点问题，特别是对于业务来说，原有的 Jenkins 流程会经常出现问题，例如工区断网、Mac 机无法连接等问题，这些都会对业务产生影响。因此，我们需要将具体影响业务的点拿出来，一个一个去解决。首先，Pipeline 是一个需要重点解决的问题。我们的目标是在公司内部统一 Linux、Windows、macOS 等执行环境，比如 RTC 可能需要支持这三个环境。通过插件市场和插件试讲的形式，使得该作业更加通用。例如，如何将抖音的作业应用到头条中？同时，高度自定义，紧密结合研发流程，就是前面展示的那几点。

下面这张图展示了整个应用架构中的 Pipeline 模块。其中，重点介绍下自建集群模块。我们目前有三种集群，分别是 Linux 集群、Windows 集群和 Mac 集群。

下面的图是一个用户可以使用的页面，用户可以在这个页面中编排自己的 Pipeline。例如，当抖音的发行包构建完成后，用户可以在这里设置静态检查任务，以确保代码没有问题，并上传构建包供 QA 测试。

下图展示的是我们 Pipeline 的原子市场，提供一些标准的官方 Job，比如包大小检测。字节内部、业务团队会有一些特别好的工具，检测完成后放到官方 Job 中，通过标准定义放进来，其他业务就可以使用了。例如测试团队的单元测试、静态检查、工具链团队为他们做的安卓编译和 iOS 编译。这样收敛后有一个好处，工具链团队做的分布式编译优化只需要在三方 Job 2 上集成插件，全公司就能使用了。

下图展示的是我们团队针对于 Pipeline 建立的 Mac Mini 机房。我们经历了三个阶段。在第一阶段，我们把迷你电脑放在自己的工位旁边，但由于我们经常搬家，每一次搬家都需要发公告通知云构建停机一天，这对于稳定性来说是不利的。另外，由于北美的研发不断增加，我们需要保证机器能够 24 小时不停地运行，而这在单一的机房里是不可能实现的。因此，我们建立了两个办公室、两个办公楼来满足需求。目前，我们已经将整个云构建迁移到标准的 IDC 中，用了 3000 台 Mac Mini。为了解决并发执行的问题，我们在 Mini 上建立了 Mac OS 的执行环境，并进行了虚拟化。

集成区

最后一步是将代码合并到对应的版本中，我们采用基于版本的理念，也就是基于版本驱动。APP 会以固定的时间周期进行发布，因此需要知道哪些需求需要与哪些版本一起发布。这个集成区用于管理这些问题，其中核心有四个功能。

日历

下图展示了我们的版本日历，它规划了半年内每个版本的计划。这个日历的目的是让 QA、RD 和 PM 等多个角色能够协同工作。对于抖音而言，它有多个时间节点，比如每周都有版本计划，每个版本计划包括发版日期和封版日期等。通过这个日历，各个角色可以更好地进行协同工作。

准入

下图是准入页面，用于控制哪些 MR 没有申请 Ticket，这主要针对重保的一些功能。

状态流转

这里展示了一个状态流转的示例。一旦一个 MR 合并后，它就会与一个具体的需求关联起来，并将 MR 的所有状态同步到需求管理平台上。

例如，对于 iOS 开发来说，如果有一个安卓需求，那么在整个节点中，一旦有一个 MR 关联到该需求，该节点将自动向后流转并变为绿色。对于 PMO，他们会知道这个功能的 MR 已经被创建了，这意味着它已经完成开发，随后是安卓测试。一旦 QA 完成测试，该节点也会向后流转。因此，整个节点流转是全自动的。

以上就是我分享的内容，谢谢！

演讲人介绍

李腾飞，字节跳动后端研发工程师。目前主要工作重心在 Mobile DevOps 的平台服务开发和 Mobile 新研发流程的探索。2019 年加入字节，主要从事端相关的基础服务建设，参与过 Web 服务监控平台的开发。

相关阅读：

开源爱好者，字节跳动这项技术，正式宣布开源了

字节跳动的开源历程与价值思考

字节跳动正式开源分布式训练调度框架 Primus

字节跳动副总裁杨震原：好的 AI 基础设施，如何激发...