从零开始搭建一个前端资源自动化构建发布系统(中)

前言

接上篇从零开始搭建一个前端资源自动化构建发布系统(上),本来想写一个长篇,这个世界好玩儿的东西太多,前段时间在干别的,上一篇在我的草稿箱躺了很久,所以分成了多篇。

上篇说到提交代码要进行构建和发布,前提是分支或者tag格式满足条件,但是不能不分青红皂白直接构建和发布,需要做一些检查。

构建前的检测

  1. 检测当前group是否开通了发布权限,这个是为了清楚的知道哪些用户在使用,方便以后有变更能清晰的知道应该通知哪些人。
  2. 检测本次提交的的版本号是否已经发布过正式线,如果发布过则停止发布。首先正式线不应该覆盖之前的版本,因为我们现在都是非覆盖发布嘛,其实日常和预发也不应该覆盖之前的版本,一旦一个版本正式发布则日常预发正式三套环境就应该是不可变的了。

  3. 检测版本是否递增,这个只在正式线做,因为递增的版本更符合人类的认知。

  4. 检测代码新鲜度,前文说过以master为准。举个例子,假如你在1.0.2分支开发,有人发布了1.0.1版本(正式线),因为发布成功会将1.0.1合并到master,所以1.0.2需要从master merge。

发布前的检测

发布前需要检查是否有构建的结果,这个相对简单。

发布后的检测

发布后链接是否可用需要逐个校验一下,如果发布除了问题,直接上线就虾米了。

其他检测

根据各公司的实际情况来了,有一些不方便写出来。

如何优雅的做检测

每一个检测规则都把他规划成一个validator,具体应用哪些validator在配置文件中配置,这也符合上一篇文章提到的配置+模式的原则。日常、预发、测试又可以应用不同的validator,以及应用的顺序也可以灵活调整。

发布

发布要分为三个模块来做,分别是日常发布模块、预发发布模块、正式线发布模块,在主流程模块中引入直接调用即可,这样可以保证扩展性,发布方式有调整只需要修改相应的发布模块即可,主流程不变。而发布方式可能有依赖多个其他模块,如OSS文件上传模块,作为一个独立的上传适配器来封装,如果哪天我们不用阿里OSS了,我们改用七牛、又拍、AWS,我们只需要按照实现一个相应云存储的适配器并在config中配置即可。

结束

还有后续,没写完。

可能有一天我们会开源。

推荐文章