BIGO前端CICD平台

本文首发于：https://github.com/bigo-frontend/blog/ 欢迎关注、转载。

我是谁

BIGO前端CICD平台，是一个服务于前端团队的全研发周期管理平台，已经是我们团队日常都要使用的工具了。

该平台实现了一键创建项目、发布编排、新建迭代、checklist、快速发布、快速回滚等能力。

统一了前端研发规范、脚手架治理、升级流程管控，打通内部多个研发系统，简化了升级步骤。

技术栈：vue.js+element-ui+eggjs

新建项目：

迭代列表：

扩展任意流程

业务的需求是无限的。即使整合好了现有流程，业务还是会不断提出一些平台无力承载的需求。这时扩展任意流程的能力就非常必要。让业务自己开发相关需求，然后集成到 CICD 平台即可。

怎么集成呢？我们先看下业界的做法，基本都是定义一些基础的 job，然后在 pipeline 的配置文件中自由组装 job。当然不同系统的“pipeline”和“job”的用词可能不同，但都是原子任务和装配流水线的意思。感兴趣的可以进一步了解开源的 Jenkins，Gitlab，大厂自研的美团 Pipeline，字节的宇宙大系统等。

前端 CICD 平台的解决思路类似。我们不需要这么高的组装自由度，因为大多前端特有的流程，都被我们内化到平台中了。前端发布的 pipeline 在项目设置中配置，业务 job 使用 webhook 的形式接入。

界面截图如下：

接入点目前只开放发布前和发布后。流程和接口规范可以参考下图：

建设特色能力

好了，现在平台已经整合好了现有流程，也能扩展任意流程了，是不是万事大吉了呢？如果是的话，那平台存在的意义就不大了。用不着做“前端”的 CICD 平台。平台针对前端的定制功能，是前端 CICD 平台重要的加分项。

checklist 功能

checklist 是一种成本低，效用高的工具。上线前，我们可以使用 checklist 来确认产品验收情况、外链情况、埋点情况、配置上线情况等，从而有效避免低级错误。不同业务线的 checklist 可以配置不一样。

验收观察功能

需求上线后，需要及时验收和观察。不是所有的问题都能通过自动监控发现，人工观测还是必要的。平台会在上线后定时推送观察提醒，减少因观察不及时导致的问题。同时，我们提供二维码生成器，方便开发者在端内打开。

产物域名扫描功能

在一个典型的前后端分离的项目中，有测试、灰度、生产三个环境。前端项目中包含一份代码，三份配置。产物打包时，测试环境产物是根据代码和测试环境配置生成的，它的 XHR 请求 url 应该是后端的测试域名。以此类推，灰度产物应该访问后端的灰度域名，生产产物应该访问后端的生产域名。

如果开发测试阶段，后端请求域名写在了代码，而非配置文件中呢？灰度和生产的产物，就会访问后端的测试域名了。这种错误在测试和灰度阶段可能无法发现，等上了生产，就会酿成事故。

针对这种情况，我们有一些 webpack 插件等工具可以使用。但是 webpack 插件起效需要重新安装发布，而存量项目有几百个，改造成本太大。所以需要前端 CICD 平台提供统一的产物域名扫描功能，用于兜底。

技术细节方面，我们在构建过程插入一行 shell 脚本，将特定后缀的产物都当做文本处理。通过正则规则，识别出疑似域名的字符串。字符串数组去重后，将它们发送到服务端统一汇总处理。处理结果通过公司的 IM 消息异步推送。

平台统一处理的好处是能统一管理域名黑白名单。而且能保证所有上线的项目都能有效覆盖到。

当然，平台针对前端的定制功能不止以上几点。有些实用功能是为了解决特定的历史遗留问题的，虽然对我们很重要，但不在这里展开讲述了。

这些前端特色功能规范了流程，降低了线上事故率，提升了特定场景的效率。

写在最后

CICD 平台是通过提升研发效率，间接产生业务价值的平台。我们不会像一线大厂那样不计成本地卷效率，而是在人力投入与团队提效之间做了平衡。一年半以来，间断投入 1.5 人力，才建设成为今天的前端 CICD 平台。

希望我们的历程，能给正在建设平台的你一点参考。

欢迎大家留言讨论，祝工作顺利、生活愉快！

我是bigo前端，下期见。