自研前端秒级别构建平台总结

该文章阅读需要 7 分钟,更多文章请点击本人博客halu886

自研秒级别构建平台总结

@兔几直播是一款主打交友的秀场直播平台,前端部门累计 8 人+,主要负责 PC 主站/H5 的视图层及 Node(BFF)层,以及 6 个+内部数据可视化系统。

在一个长期快速迭代且多人协作的中大型项目中,前端部署自动化一直都是团队的痛点,以下则是我们团队在基于多样的场景自研的 web-ci 完整版心路历程,实现前端部署一键化/可视化,同时将耗时从 30min+缩短为 3s 左右。

背景

我们项目架构是采用前后端分离,BFF 基于 EGG 搭建,前端页面集成 MVVM 框架 Backbone.js/Vue.js,工程化打包工具则采用 fis。

我们将各个前端业务拆分成一个个完全隔离的 repo(累计 10 个+),在项目 run 起来之前,

需要将涉及到的 repo 基于我们自定义的 fis 配置规则

通过 fis 将源码打包成标准的 EGG 结构的项目(pc-master),然后启动 pc-master

所以无论是线上还是本地都是通过 pc-master 实现服务

基于 CDN 加速

最开始我们部署流程是通过 web-ci 服务处理如下几步,并且线上搭建四个源站且集成 aliyun CDN 加速和缓存服务进行支撑业务

  1. 开发者向部署分支(master/test)合并提交且推送至远程仓库
  2. 触发 gitlab 配置的 web hook,通知 web-ci 新建任务执行构建任务
  3. web-ci 服务执行相关命令
    1. 将云端公共仓库同步于服务中的相关仓库
  4. 将所有 repo 打包进 pc-master 中
  5. 上传 pc-master 相关源码及资源至源站
  6. 启动服务

1

由于 cdn 的缓存策略,在我们采用的是增量发布,结果随着项目推进却带来了一系列的弊端。

场景 1:
线上活动 A-index.html,依赖 a-123.js/b-123.css(资源文件通过打包注入的 HASH 值进行区分其版本)

开发人员发现由于线上流量过大,对相关服务端接口做了节流处理,更新源码后合并到发布分支且推送到远程仓库。

此时 web-ci 重新打包,重新生成相关依赖静态资源 a-456.js,由于是增量发布,那么此时该活动的静态资源目录则变成 a-123.js,a-456.js,b-123.css blabla。

将相关打包后的文件上传至源站的体积就变大了。

随着项目快速迭代,打包后的 pc-master 逐渐变得越来越庞大,由几十 KB 涨到以 GB 为单位,即时是在局域网传输也需要耗费二三十分钟左右,那么这对于开发人员肯定是极度不友好的。

为什么需要做增量发布?为什么不能删除旧的资源文件?

cdn 网络具有缓存且缓存具有时效性,当用户通过地址访问 html 文件时,
一旦命中 CDN 的缓存,html 依赖的还是旧的静态资源,那么此时则请求 a-123.js 文件。

假如该文件在 CDN 网络的缓存已经过了时效性或者没有命中缓存,经过 CDN 回源策略最后请求回到源站,

一旦发现文件不存在,那么对于用户来说,该网站则是不可用或者异常的。
对于商用的产品这个问题肯定是不能接受的。

集成 OSS

基于上述痛点我们决定通过集成 OSS 对象存储服务,并且在构建过程中引入一个中间目录进行过渡且增加灵活性。

  1. 开发者向部署分支(master/test)合并提交且推送至远程仓库
  2. 触发 gitlab 配置的 web hook,通知 web-ci 启动构建服务
  3. web-ci 服务执行相关命令
    1. 将云端公共仓库同步于服务中的相关仓库
  4. 将所有 repo 打包进 main-pc 中
  5. 执行脚本将相关静态资源文件上传逻辑至 aliyun OSS 服务中
  6. 将 BFF 层 script 及相关 html 资源文件 cp 到 main-pc-release 中
  7. 触发 walle 将 main-pc-release 同步到源站重启服务

2

仔细观察流程则可以发现多了第 6 步 upload all the static resource。

 这个思路的本质则是将我们的增量发布从源站转换到 OSS bucket 中,

在 OSS bucket 稳定的前提下,我们只需对每次新生成的个别文件进行上传操作,并且每个有文件都存在唯一的哈希值保证唯一。

完美的在 web-ci 服务中规避了由于增量发布带来的维护旧文件所带来的成本。

并且最后源站执行的是 main-pc-release 项目,此时项目已经剔除所有非必要的静态资源的文件,

源码本身只存在 BFF 层相关的业务代码和 html 文件。则在第七步中传输到源站耗费的时间完全可以忽略不记

这时从开发者提交代码,到代码构建完成全流程只需要秒级别,大幅度的提升了开发人员的效率

可视化

为了提升构建服务本身的也易用性,同时搭建可视化看板实时读取日志,且加入了回滚及及销毁等个性化操作。

web-ci

例如:web-ci 内置启动一个 web 服务,对每步流程都进行进行日志写入,当前如果有任务执行,且日志正在写入中,看板则会发起一个 http 请求,web-ci 则将 log 文件可读流转发至 response 响应流中,实现同步显示 log

web-ci-log

总结

优雅的构建流程是前端工程化中不可或缺的一部分,如何实现易用且高效的方案每个团队的侧重点都有所取舍。

不论是基于第三方构建平台或是选择自研搭建,核心都诉求都是尽可能都节省时间及人力。

以上就是我们团队相关历程的总结,欢迎拍砖及讨论:halu.hong1996@gmail.com

halu886`s 公众号

谢谢老板,老板必发大财!💰💰💰💰💰💰