百度 APP 基于 Pipeline as Code 的持续集成实践

2022 年 6 月 28 日
本文字数：6382 字
阅读完需：约 21 分钟

全文 8150 字，预计阅读时间 21 分钟

一、概述

百度 APP 经过多年 DevOps 的建设，已经形成了一套从计划、开发、测试、集成到交付的标准工作流和工具集。其中，持续集成（Continuous integration，简称 CI）作为 DevOps 最核心的流程之一，通过频繁地将代码集成到主干和生产环境以执行预置的自动化任务。

CI 一直是我们百度移动研发平台——Tekes，支撑百度 APP 研发流程的重要的切入点，我们的自动化研发流程（组件自动发布、准入等）都是基于 CI 的实践，已经支持百度 APP 发版 50+次，准入 40w+组件和 SDK。但当这些自动化研发流程输出到其他产品线时，却遇到了一个问题：不同产品线对研发流程存在定制化需求，例如百度 APP 在中台化组件发布前需要检查 API 及依赖的变更情况，并在有不兼容变更的情况发生时发起人工审批；而好看 APP 只需要将不兼容变更展示在发布完成后的报表之中，这就导致了我们预置的流水线模板无法直接复用。为了解决这个问题，一种可行的方法是让产品线用结构化的语言去描述他们研发流程需要的一组功能或特性，然后根据描述自动化地生成对应的流水线，这种思想其实就是 Pipeline as Code（流水线即代码，PaC）。

二、Pipeline as Code

Pipeline as Code 是 “as Code” 运动的一种，引用 Gitlab 官网对 Pipeline as Code 的解释：

Pipeline as code is a practice of defining deployment pipelines through source code, such as Git. Pipeline as code is part of a larger “as code” movement that includes infrastructure as code. Teams can configure builds, tests, and deployment in code that is trackable and stored in a centralized source repository. Teams can use a declarative YAML approach or a vendor-specific programming language, such as Jenkins and Groovy, but the premise remains the same.

提到 “as Code” ，我们最容易想到 Infrastructure as Code (基础设施即代码，IaC) ， IaC 是将基础设施、资源及环境使用 DSL（Domain Specified Language，领域专有语言）编码，例如 Ansible 的 playbook 就是一种基于 YML 的 DSL，一个在 macOS 系统上标准化安装 Xcode 的 playbook 简单示例如下：

# playbook- name: Install Xcode  block:    - name: check that the xcode archive is valid      command: >        pkgutil --check-signature {{ xcode_xip_location }} |        grep \"Status: signed Apple Software\"    - name: Clean up existing Xcode installation      file:        path: /Applications/Xcode.app        state: absent    - name: Install Xcode from XIP file Location      command: xip --expand {{ xcode_xip_location }}      args:        chdir: /Applications      poll: 5      async: "{{ xcode_xip_extraction_timeout }}" # Prevent SSH connections timing out waiting for extraction    - name: Accept License Agreement      command: "{{ xcode_build }} -license accept"      become: true    - name: Run Xcode first launch      command: "{{ xcode_build }} -runFirstLaunch"      become: true      when: xcode_major_version | int >= 13  when: not xcode_installed or xcode_installed_version is version(xcode_target_version, '!=')

复制代码

如同 Ansible，我们也使用了类似的方案对流水线进行 DSL 编码并纳入版本控制，除了能解决我们遇到的不同产品线差异化配置的问题，他还有很多其他优点，例如：

“

让产品线团队只需要关注流水线当前版本的 DSL，方便团队内部成员共同维护和升级；
流水线本身的环境配置也是 DSL 的一部分，消除流水线环境由于配置混乱造成的特异性；
DSL 非常容易复制和链接代码片段，可以将 CI 脚本组件化之后作为一种可配置的 DSL 单元。

不过在介绍我们的方案之前，我们先介绍下业内比较有代表性的两种方案：Jenkins Pipeline 和 Github Actions。

Jenkins Pipeline 是 Jenkins2.0 推出的一套 Groovy DSL 语法，将原本独立运行于多个 Job 或者多个节点的任务统一使用代码的形式进行管理和维护。

GitHub Actions 是 GitHub 推出的自动化服务，通过在仓库配置一个基于 YML 的 DSL 文件来创建一个工作流，当仓库触发某个事件的时候，工作流就会运行。

我们举一个简单的 Xcode 工程编译的例子来体会两者 DSL 语法的区别，包含三个步骤：

“

Checkout：从 Git 服务器下拉源码
Build：执行 xcodebuild 编译命令
UseMyLibrary：引用自定义的脚本方法

Jenkins Pipeline 的 DSL 如下：

// Jenkinsfile(Declarative Pipeline)@Library('my-library') _pipeline {  agent {    node {      label 'MACOS'    }  }  stages {    stage('Checkout') {      steps {        checkout scm      }    }    stage('Build') {      steps {        sh 'xcodebuild -workspace projectname.xcworkspace -scheme schemename -destination generic/platform=iOS'      }    }    stage('UseMyLibrary') {      steps {        myCustomFunc 'Hello world'      }    }  }}

复制代码

Github Actions 的 DSL 如下：

# .github/workflows/ios.ymlname: iOS workflowon: [push]jobs:  build:    runs-on: macos-latest    steps:      - name: Checkout        uses: actions/checkout@v3      - name: Build        run: xcodebuild -workspace projectname.xcworkspace -scheme schemename -destination generic/platform=iOS      - name: UseMyLibrary        uses: my-library/my-custom-action@master        with:            args: Hello world

复制代码

可以看到两者 DSL 的表述都非常清晰简练，很多语法甚至可以相互转换，实际上 DSL 不是 PaC 首要的选型依据，而是看业务使用何种持续集成系统。

Jenkins 是一个完全自托管的持续集成系统，使用 Groovy 脚本来定义 Pipeline 也提供了极大的灵活性。而 Github Actions 与 Github 高度整合，可以直接使用，并且 Workflow 的 YML 是一种组件化设计，结构清晰，语法简单。可以说两者各有千秋。我们业务使用的持续集成系统是百度自研的 iPipe，我们在做 PaC 的实践时第一原则是使用公司的基础设施，避免重复造轮子，因此我们采取了一种创新的方案和系统——Tekes Actions。

三、Tekes Actions

从命名可以看出 Tekes Actions 参照了 Github Actions ，DSL 语法也基本照搬 Github Actions，例如百度 APP 组件发布流程的 DSL 如下：

# baiduapp/ios/publish.ymlname: 'iOS Module Publish Workflow'author: 'zhuyusong'description: 'iOS 组件发布流程'on:  events:    topic_merge:      branches: ['master', 'release/**']      repositories: ['baidu/baidu-app/*', 'baidu/third-party/*']jobs:  publish:    name: 'publish modules using Easybox'    runs-on: macos-latest    steps:    - name: 'Checkout'      uses: actions/checkout@v2    - name: 'Setup Easybox'      uses: actions/setup-easybox@v2      with:        is_public_storage: true    - name: 'Build Task use Easybox'        uses: actions/easybox-ios-build@v1with:          component_check: true          quality_check: true    - name: 'Publish Task use Easybox'        uses: actions/easybox-ios-publish@v1    - name: 'Access Task use Easybox'        uses:actions/easybox-ios-access@v1

复制代码

其实上一节提到了 DSL 本身不是 PaC 最关键的点，我们选用 Github Actions 的 DSL 主要原因是因为其组件化的工作流程可以很好地与我们 Tekes 平台以及公司的持续集成系统进行融合。

我们先介绍 Github Actions 官方文档的工作流程，附上示意图：

工作流程包含一个或者多个作业（Job），由事件（Event）触发，在 Github 托管或自托管的运行器（Runner）上运行。下面介绍这几个核心组件：

1. 作业：每个作业由一组步骤（Step）组成，每个 Step 是可以运行操作（Action）或者 Shell 命令的单个任务，Action 可以看作封装的独立脚本，可以自定义或引用第三方。

2. 事件：事件是触发工作流程的特定活动，例如推送代码、拉取分支、创建问题等。本来 Github 就提供了非常丰富类型，可以很方便地作为 Github Actions 的触发源。

3. 运行器：运行器是运行触发后的工作流程的服务，GitHub 提供 Linux、Windows 和 macOS 虚拟机环境的运行器，也可以创建自托管运行器运行在自定义的环境中。

Action 是组成工作流程最核心最基础的元素，可以说正是因为有了 Action 这种可复用扩展的设计，给 Github Actions 生态带来了极大的活力，Github 不仅提供了许多官方的 Action，并且还搭建了一个 Action 市场，可以搜索到各种三方 Action，让实现一个工作流程变得非常简单。

Tekes Actions 在作业、事件和运行器这三个组件上都有自己特色的设计：

作业上，Tekes 通过 Action 可复用扩展的这种思想，把自己多年建设的 CI 脚本分解成 Tekes 官方的 Action，让产品线可以自由插拔到自己的研发流程中，实现定制化流水线；同时开放出 CI 的能力，搭建了一个公开的 Action 制品库，支持保障组件化、质量、性能等角色可以上传自己的 Action，共同建立 Tekes 生态。

事件上，由于 Tekes 在建设移动 DevOps 服务时抽象了自己的事件类型，我们将此作为 Tekes Actions 工作流程的触发源。并且由于我们的事件并不是和仓库一对一的关系，我们还设计了一个产品线流程编排的服务和事件处理的服务，前者用来帮助产品线管理工作流程的 DSL 文件，后者用来裁决何种事件应该触发何种产品线的何种工作流程。

运行器上，我们完全实现了运行器用来解释执行工作流程的 DSL，包括监听触发事件，调度 Job，下载 Action，执行脚本，上传日志等功能，并支持 Cli 命令本地调用，方便流水线开发者在自己本地的工作区中进行调试；同时远端的运行器跑在我们虚拟机集群，当工作流程触发时我们通过 iPipe Agent 去调度。

iPipe Agent 是一个基于 iPipe 的代理服务，可以直接调度到我们的虚拟机集群并分配一台全新的包含指定系统和运行器的虚拟机。

整个 Tekes Actions 的工程架构如下图所示：

工程上，Tekes Actions 采用了一个完全基于百度云的 Serverless 服务，核心的事件处理服务只是一个云函数服务，这个云函数服务负责处理两种事件源：

1. 流程编排。产品线创建和更新工作流程时会生成一个 YML 文件，上传到 DSL 文件服务的该产品线的目录下，DSL 文件服务的文件新增和更新事件会通知云函数，用来新增和更新数据库服务存储的触发规则；

2. 事件。例如 DevOps 服务产生的组合入事件，这些事件会发布到消息服务特定的 topic 中，云函数订阅这个 topic 以接收事件，用来匹配数据库服务存储的各个产品线工作流程触发规则，并在匹配成功时调度一个运行器。

四、Tekes Runner

Tekes Runner 是运行 Tekes Actions 工作流程的工具，架构图如下：

Tekes Runner 服务层由 Template、Worker 和 WebAPI 三个模块组成，分别负责读取和校验 DSL 文件、管理工作流程以及与后端服务通信，其中 WebAPI 模块是可以在配置文件中关闭的。

Tekes Runner 在交互层的命令模块提供了四种 Cli 命令，分别是 Run、Pause、Unpause 和 Kill，都是管理工作流程生命周期的命令。工作流程生命周期如下图所示：

当执行 Run 命令时， Tekes Runner 首先会根据配置来初始化 Tekes Actions 工作流程，包括读取对应工作流程的 YML，下载并校验依赖的 Action，创建工作区等，成功之后进入 initialized 状态。

接着会根据解析后的工作流程对象创建一组状态机并运行，每一个作业对应一个简单的有限状态机（Finite State Machine， FSM），此时进入到 running 状态。

状态机的现态是当前执行的阶段，触发状态迁移的事件是脚本运行的结果。

当整个状态机组的所有状态机都迁移到结束状态（无论是否成功），工作流程就会结束，进入 stopped 状态。此外，如果工作流程超时或者接收到外部的 Kill 命令，也会进入 stopped 状态。

现在我们已经实现了一个可以在本地运行脚本的简单运行器了，但还有几个细节需要进一步阐述：

丨细节 1. Action 和 Runner 的交互方式

Action 和 Runner 交互是一个非常常见的行为，例如从 Runner 获取输入写入输出，又或者将执行结果通知 Runner。

Action 和 Runner 有三种交互方式：

环境变量：Runner 将需要传递给 Action 的参数写入环境变量中，一般包括 Action 所需的输入以及一些上下文；
工作区文件：Runner 将需要传递给 Action 的文件放入工作区特定的文件夹中，一般是 Action 所需的中间产物；
Action 的打印：Runner 在执行 Action 的过程中会不断监听 Action 的打印内容，Runner 和 Action 约定了一套带有特殊命令标识符的打印语句，当 Runner 监听到此类语句时会解析并执行预设的命令，包括设置输出，打印日志和上传产物等。