背景

故事要从两年前说起，那时知乎调整了移动客户端的发布流程，确立了每两周一次的固定发版周期，这期间包含了需求产生、设计、开发、测试等一系列的流程。当时业务发展的速度与现在相比并不快，整体的工作流都是围绕着 Gitlab 、Jenkins 、Slack 等工具，即在 Jenkins 上打包和测试、在 Gitlab 上通过 MR 的方式管理代码改动、通过 Slack 接收流程中的各项通知。

每个 MR 在创建或提交新代码时都会自动触发 Jenkins 打包，MR 相关各角色可以方便地安装这个包进行验收和测试。在 Gitlab MR 中，我们设置了如下图的一系列标签（Labels）用来标记各角色的验收结果，只有集齐这些标签的 MR 才能被合并，其中 Dev 、PM 、Design 、QA 标签分别代表开发自测通过、产品验收通过、设计师验收通过以及 QA 测试通过。

一个典型的知乎客户端 MR

不过随着知乎用户量的快速增长，移动客户端功能也越来越复杂，开发团队也相应扩大，与此同时在知乎客户端的开发和测试过程中出现了如下问题：

• 代码耦合严重
• 依赖关系复杂
• 业务职责混乱
• 频繁的代码冲突
• 代码难以复用
• 高风险功能影响版本发布
• 。。。

总之，老的客户端架构和发布流程开发效率低、测试效率低、功能迭代慢，渐渐不再适应业务的发展。于是在 2017 年底，知乎走上了移动客户端组件化之路，对于组件化的一些概念，这里不再赘述。而组件化给我们带来的新的挑战是，如何在每次应用迭代的过程中清晰地管理大量的组件信息、组件之间的依赖关系、应用与组件之间的依赖关系，如何能快速获取构建结果，如何能在不同测试阶段发现 Bug 时快速定位到问题所在等等。

这些新的挑战最终转化成需求，造就了知乎移动端组件管理平台 Athena 。将 Gitlab 、Jenkins 在日常迭代中的工作流的作用弱化，取而代之的是一个集成式一体化的平台，无论是产品、设计、开发、测试，在这个平台上可以很清晰的查看操作所需的组件或应用资源，节省在各个工具之间上下文切换带来的低效能，以及团队内部沟通的成本。工具的平台化同时也代表着工作流程的规范统一，通过使用平台的权限控制，使得移动端发版工作流程更加明确统一。对于新入职的员工，无需再花费大量时间理解消化复杂的流程，只需要按照平台的使用说明，即可快速上手工作。

多说一句，我们使用 Athena 命名平台，正是因为 Athena (希腊神话中的女神) 主司智慧和公正。我们希望 Athena 的诞生能减轻工程师在移动端开发流程中的心智负担，并公正客观的实现统一有效的流程规范。

架构

知乎移动客户端组件管理平台 Athena 是基于 B/S 的架构，采用前后端分离的策略，前端主要专注于友好的交互和清晰的资源展示，后端则主要负责资源的业务逻辑处理以及与其他工具的交互。

关于前端选型，我们使用了当前趋势迅猛的前端框架 Vue 以及官方推出的一系列生态圈产品 Vue Router, Vuex 来搭建。Vue 是一款渐进式的前端框架，这对于平时主要工作集中在后端项目的工程师相对比较友好，学习曲线没有 React 陡峭，其提供了丰富的 API 供用户使用，同时官方的脚手架工具 Vue CLI 可供用户快速搭建应用。

关于后端技术选型，我们选用知乎自研的基于 tornado 的定制 Restful API 框架来搭建，选用 MySQL 负责数据存储，同时使用知乎自研的部署发布引擎来执行平台的部署发布。

同时，Athena 希望在工作流中将 Gitlab 和 Jenkins 弱化，因此我们对二者的常用 API 进行了封装供 Athena 调用，用户只需要在 Athena 上进行操作即可，由 Athena 触发 Gitlab 和 Jenkins 完成各项任务。另外，用户在 Athena 上的任何操作都会使其在 Slack 上收到即时通知。

主要功能

作为移动客户端的组件管理平台，Athena 的主要功能表现为以下两点：

• 组件管理
• 组件集成

组件管理

组件接入 Athena 的前提是拥有自己独立的 Gitlab 代码仓库，且目录结构符合知乎客户端组件规范。目前 Athena 需要人工录入组件，用户使用「添加组件」的功能将组件接入至 Athena 平台后，Athena 会自动为该组件代码仓库添加 Webhook 用以监听代码仓库中的变更。

同时可以看到，当用户在平台添加组件的时候，我们设计了一些组件维度上的权限管理。只有组件的负责人拥有平台上组件的所有操作权限，并且组件的负责人可以自定义配置组件验收过程中所需的角色标签 （包括 Dev 、 PM 、Design 、 QA ），配置好的角色会在组件验收流程中做相应的验收工作。这里的标签与上述 Gitlab MR 中的标签功能一致，有了这些标签，我们便可以将各角色的验收工作从 Gitlab 迁移到 Athena ，从而达到弱化 Gitlab 在流程中作用的目的。任一角色未通过验收，该组件版本就不能作为集成候选版本。这样我们统一了各组件的集成规范，与此同时也给予用户一定程度的自由。

每当组件负责人在代码仓库中修改了组件的版本号 ，代码仓库的 Webhook 将会被触发从而去调用 Athena 的接口，Athena 则会为以 Gitlab Tag 的形式为该组件创建一个新的版本。同时 Athena 还会自动发布组件新版本的 aar（Andoid 组件）或 Framework（iOS 组件）。用户可在 Athena 平台上浏览组件的新版本以及此次组件更新的内容。

组件发布流程

组件集成

组件集成是指将知乎主 App 依赖的组件升级到新的版本，在组件化之后，我们用组件集成来代替原流程中的 MR 。用户在 Athena 上选择组件的新版本并构建集成包来验收，打包也是由 Athena 触发 Jenkins 来完成的。各业务团队各自在上文提到的组件配置中决定集成验收参与的角色，所有角色验收通过后，QA 便可以在 Athena 平台上将主 App 所依赖的组件升级到指定的版本。

组件集成流程

如下图所示，用户在指定的主 App 版本上可以找到对应组件的各个版本，对指定的版本构建集成测试包，如果此版本通过了验收，则可以集成至相应的主 APP 版本中。

组件各版本列表

基于指定组件版本打集成测试包

如此一来，凡是接入到 Athena 平台上的组件都抛弃了原始的散养式的管理，而遵循一套统一，清晰且高效的迭代流程。组件发布流程独立且快速，业务团队内部不同职能的员工沟通成本降低，工作效率提升。为今后移动端更加快速的发版奠定了基础。

展望未来

自从 Athena 平台上线半年多来，已经经历知乎移动端发版 30+ 次，在此期间 Athena 已经：

• 接入移动端客户端组件总计 70+ 个
• 完成组件新版本的自动发布共计 2500+ 次
• 完成组件集成测试包的构建 600+ 次
• 完成组件集成 400+ 次

同时客户端的迭代流程也越来越稳定，Athena 持续为提升知乎移动端质量与发布速度保驾护航。

我们当然不会满足于现状，Athena 女神的智慧也绝不仅限于此，我们计划在后续的工作中赋予她更多的使命：

• 去 Jenkins 化

Athena 依赖 Jenkins 来实现构建任务的管理以及分配，维护 Athena 的同时，我们还需要维护 Jenkins 上的配置。这样造成了维护和使用成本的上升，我们希望未来 Athena 可以完全摒弃 Jenkins 来实现构建的分配和执行。

• 自动化测试

目前组件的测试自动化程度还不高，同时 Athena 对自动化测试的支持也并不好，未来我们会使 Athena 接入更多自动化测试，真正实现组件的持续集成和持续发布，提供更全面的质量保障。

• 质量数据收集与可视化

质量数据的重要性不必多说，我们希望能够将迭代流程中各个环节的数据收集分析（静态代码扫描、单元测试、包大小检查等），作为组件持续集成流程的准入规则，形成一套更加智能完善的闭环系统。

作者:钟离无糖

出处:https://zhuanlan.zhihu.com/p/46411733