To B前端 CI/CD建设实践

本文分享自百度开发者中心To B前端 CI/CD建设实践

背景
去年末团队接手负责 30 多个面向 ToB 的平台系统，系统多，需求紧，人力缺口一直存在，主要问题体如今：

1. 先后端部署耦合：先后端资源部署在同一 Web 容器，后端上线会带着前 端，一样前端也会带着后端；
2. 研发流程不规范：各平台缺乏统一的规范，好比分支规范，部署规范，联调规范等；
3. 研发质量保证：缺乏基本的质量保证手段，好比前端单元测试，先后端接口变动流程等；

经过技术手段提升研发效率一直是咱们追求的目标。今年经过对业界和公司内部爱番番团队的相关技术调研，决定对现有研发流程进行改进规范，经过 CI/CD 能力建议，提升研发效率和下降运维成本（感谢爱番番团队的 CI/CD 工做！）

今天主要从如下方面来讲明 CI/CD 针对 ToB 场景的最佳实践，除了说明作了 What 外，更重要但愿能从价值收益上说明 How 和 Why。（注：ToC 与 ToB 各方面差别较大）

什么是CI/CD

简单理解：Continuous Integration/Continuous Deployment

深刻理解：基于新兴的 DevOps 文化，以管道的形式，经过自动化构建、测试和部署，缩小开发团队和操做团队之间的差距，以到达快速稳定的交付目的。

名词解释

1. Devops
   DevOps 是 Development 和 Operations 的组合，是一种思想、一组最佳实践、以及一种文化，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协做与整合。以期打破传统开发和运营之间的壁垒和鸿沟。

2. CI
   CI 即 Continuous Integration 的缩写，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，须要通过编译和自动化测试流进行验证；

3. CD
   CD 可对应多个英文名称，持续交付 Continuous Delivery 和持续部署 Continuous Deployment；

• Continuous Delivery
  完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确 CI 已内置于开发管道。
  持续交付的目标是拥有一个可随时部署到生产环境的代码库。

• Continuous Deployment 对于一个成熟的 CI/CD 管道（Pipeline）来讲，最后的阶段是持续部署。做为持续交付 —— 自动将生产就绪型构建版本发布到代码存储库 —— 的延伸，持续部署能够自动将应用发布到生产环境。

涵盖范围
涵盖软件开发全生命周期，做用于各个阶段

基本原则

• 可靠性
• CI 流水线须要很快
• 独立环境中构建和运行
• 预发布环境和生产环境等价

流程规范

CI/CD 实施的基本前提条件是根据团队的技术能力现状，制定符合团队实际状况的研发流程规范。

技术全景图

研发流程规范

• 分支开发，主干测试，RB 上线
• 历史分支保留，确保随时上线发布
• 未测试代码不带到线上
• 按期检测同步代码机制，尽可能避免冲突
• 各项检查能力 CI 上落地，保障高质量交付

分支管理规范

• 代码版本分支是自动化构建的基础，开发团队必须遵照
• feature 非必需分支，各团队根据实际开发协同场景的复杂度，酌情使用
• 分支命名规范包含上线日期的作法，仅适合 ToB 场景

Pipeline 规范

• 编译：使用公司统一的集群编译
• 安全扫描：啄木鸟、猫头鹰
• 静态代码扫描：包含代码规范和潜在的 Bug
• 端测试：自动化，稳定性

云端部署（BOS/CDN)

部署设计

方案一与方案二的区别是 index.html 放在 BOS 仍是 RD 服务器？
优先推荐方案一：

• 与后端解耦更完全，html 的更新可由前端来控制
• 前端版本号管理放在 html 里，不用更新 version.js，部署更简单

方案一里有些后端可能没法配置转发；

备注：最优方案是由 BFE 配置转发规则至 BOS，不用经 RD 集群，但目前 BFE 没法直接转发至 BOS。

版本说明
前端静态资源版本通常分两种方式管理：
Hash 版本号：基于文件内容的 MD5 值，取部分长度或所有长度，作为文件的版本号，每一个文件都有不一样的版本号，适合于增量发布，节约存储空间。例如：index.abcd12.js，manifest.123456.js 等

时间戳版本号：以当前构建时间点为准，生成时间文件夹，构建结构部署在时间文件夹下。适合于全量发布。

目前选用时间戳版本号，考虑有以下：

Hash 版本，适合容器化部署，好比 Docker、Jarvis，每次包括全部资源文件；Bos 若是使用 Hash，文件夹下同名资源会有不少，显得较乱。

部署目录结构实例

performance
|---- 202101281200
|     |---- css
|     |---- js
|           |----index.js
|---- 202101291200
|     |---- css
|     |---- js
|           |----index.js
version.js
index.html

index.html 和 version.js 承担版本号维护，每次上线时更新版本号。

单元测试

现状
前端中是大部分是无测试的，国外的一项调查显示，有 43% 的 developer 没有作过任何前端相关测试，两个主要缘由：

1. 前端属于 GUI 编程，浏览器不少，要在这么多浏览器上作几轮测试，实际上是成本很高，很昂贵；
2. 某些类型的产品当中，不少时候 UI 界面迭代的更快，测试跟不上迭代；

以上两点致使前端测试不受重视，不少开发可能工做好几年年仍未写过测试。

咱们为何要作单测
ToB 业务 与 ToC 相比：

1. 业务会相对稳定：UI 页面稳定变化少
2. 稳定性要求极高：须要频繁的进行回归测试，服务的是付费用户
3. 持续升级迭代：迭代周期相对较长

单测带来的收益：

• 减小 Bug：现在的项目大多都是多人分模块协同开发，当各个模块集成时再去发现问题，定位和沟通成本是很是高的，经过单元测试来保证各个模块的正确性，能够尽早的发现问题，而不是等到集成时再发现问题；
• 放心重构：对于持续升级迭代的项目，代码不断的在变化和重构，经过单元测试，开发能够放心的修改重构代码，减小改代码时心理负担，提升重构的成功率；
• 改进设计：越是良好设计的代码，通常越容易编写单元测试，多个小的方法的单测通常比大方法（成百上千行代码）的单测代码要简单、要稳定，因此在编写单测的过程当中，若是发现单测代码很是难写，通常代表被测试的代码包含了太多的依赖或功能，须要反思代码的合理性，进而推动代码设计的优化，造成正向循环；

前端自动化测试分层

• E2E 测试：是一种黑盒测试，测试的是应用的执行是否从头至尾都按设计完成。
  整个应用程序已在实际场景中进行了测试，其中包括测试组件之间的通讯，例如数据库，网络，API 等，以及在各类浏览器中执行代码基本上测试一切。设置会花费不少时间，并且成本最高。

• 集成测试：测试程序之间的交互，例如，UI 和 API 之间的通讯。设置所需的时间较短，也不太昂贵。

• 单元测试：是最小粒度的测试，由于它包括将代码的孤立部分做为单元进行测试。这些单元能够是方法，属性，某一个 UI 元素点击、输入这样的动做等形式。例如说我有一个函数，经过入参的不一样，去覆盖逻辑的不一样 if else 这样的分支，而后去确认函数的返回值是否与咱们预期的一致，代码是否按预期执行，这就须要写断言，对于前两个测试类型来讲，这是最快，最便宜的实现方式。

能够看到在金字塔中走的越高，创建咱们的测试所花费的时间和成本（越耗时，失败时的信息越模糊，越难跟）就越多。这就是为何许多项目倾向于专一于单元测试的缘由，由于它们能够经过涵盖大多数场景，省时省力的去测试咱们的代码。

测试框架选型

Jest 表现强劲，在满意度和使用度维度都有不错的表现：

• 优秀的性能 ：对测试用例并发测试，只执行发生改变的文件所对应的测试，测试速度快；
• 集成度高 ：零配置，默认提供全部的东西，好比 Mock（干掉 Sinon）、Test Runner（干掉 Karma）、Matcher（干掉 Chai）、Test Coverage（内置 istanbul）；
• 守护模式 ：注重开发者体验，可以在编码的时候帮助咱们快速得到测试结果的反馈；

先后端规约

现状问题
随着业务逻辑愈来愈复杂，先后端分工与协做不免会出现争议，表如今：

• 存在必定的职责模糊地带，好比数据格式拼装、格式转换等工做，便可以由前端来完成，又可由后端来完成，须要屡次沟通讨论，沟通成本高；
• 先后端分离的模式下，先后端职责进行分工，致使开发沟通成本高，客户体验差（渲染速度慢，耗电高）等问题；

故制定此标准，意在明确先后端分工，减小沟通成本，减小开发维护成本，提高客户体验。

基本原则

1. 后端按业务领域拆分接口，接口数据结构避免与 UI 展示耦合。前端应关注交互渲染逻辑，根据 UI 展示须要进行数据拼装和转换；
2. 浏览器处理性能有限 (JS 单线程)，移动端续航能力有限，为了保证流畅稳定的客户体验，在批量计算，排序，分页等大数据量计算时应放到后端完成，后端返回最终结果，而非中间结果；
3. 前端网络环境复杂且不稳定 (2G/3G/4G/WIFI，进电梯等），应尽可能减小先后端网络交互次数，单页面网络请求数量不建议大于 3 个；
4. 在遇到对前端渲染速度要求极高，且后端接口数量及数据结构没法知足要求时，可作 BFF 层（Backend For Frontend）进行接口适配或者采用服务端渲染 (SSR) 技术完成；
5. 接口遵循最简原则，屏蔽业务实现细节，避免无效字段，避免暴露过多的业务逻辑，避免冗余的多级嵌套格式出现；

其余具体的约定参考阿里的《Java 开发手册》里的先后端规约章节。

工程能力地图

价值体现

工程能力地图的价值：

• 规范研发和上线流程：需求、开发、准入、测试、部署与运行全流程的最佳实践指导；
• 推荐工具链方案：全流程中推荐符合公司场景的最优工具；

YAPI平台

价值体现
不管是前端仍是后端开发，都或多或少地被接口文档折磨过。前端常常抱怨后端给的接口文档与实际状况不一致。后端又以为编写及维护接口文档会耗费很多精力，常常来不及更新，随着时间推移，版本迭代，接口文档每每很容易跟不上代码。
Swagger 提供了一套规范去定义接口及接口相关的信息，RD 只须要按照规范编写描述文件，就能够作到自动生成各类格式的接口文档，生成多种语言的客户端和服务端的代码，以及在线接口调试页面等等。

YAPI 对各角色同窗都有价值：

1. 后端同窗实现「代码即文档」，简化接口文档维护；
2. 前端同窗实时的，全自动的，更加真实的 Mock 数据，完成自动化部署服务，及自动联调工具；
3. QA 同窗实现基于 Swagger 接口数据的契约测试，结合 ITP 平台，实现自动生成契约测试；
   对总体平台的价值，主要体如今稳定性：后端同窗修改接口后，前端使用 Mock 数据，可及时发现接口变动，解决接口变动的流程沟通问题（沟通永远是最高的成本）。

>期待你的加入

>百度开发者中心已开启征稿模式，欢迎开发者进入了不得的开发者活动进行投稿，优质文章将得到丰厚奖励和推广资源。