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

前言

前端在工程化这条路上已经走了很远了。我用了约两周的时间写出了一个构建发布系统,包括研究方案和解决问题,技术的世界就是这么神奇,想想很简单,动起手来才知道有坑。技术选型当然是JavaScript,放在Node.js这个runtime上执行。

之前写了使用gitlab ci实现前端资源自动发布,本文是算是第二季,所以根本就不是从零开始,标题党了一下。

好用的发布系统应该是什么样子的。

  1. 提交代码能自动构建并且部署到测试环境。
  2. 打tag可以自动构建并将静态资源发布到CDN,技术同学把对应的入口页面或者版本号拿去发布就可以了。

好处

  1. 可以省去技术或者测试同学去干一些重复的活。提交代码不算,这个现在来看必要的。
  2. 每个版本都保留了tag。我们应该为每个版本保留一个tag,这个是不应该省的。
  3. 将权限校验转嫁给了gitlab,因为你没权限提交不了代码嘛。

    问题

  4. 不能所以提交都构建并发布,有一些提交时不需要触发的。
  5. 不能所有tag都构建并发布,道理同第一条。
  6. 版本怎么管理?
  7. 如何防止使用的同学犯错误?
  8. ……

怎么做

  1. 有一个主干分支(一般是master),主干分支保留最新的线上代码,不允许手动提交代码。
  2. daily/<x.y.z>分支提交触发构建并部署到日常环境,每次提交触发都触发。
  3. daily/<x.y.z>分支基于master创建。
  4. daily版本号可不严格递增。
  5. 一旦master有更新,daily/<x.y.z>分支需要merge后方可构建成功,否则构建会失败。
  6. prepub/<x.y.z>的分支提交触发预发构建并部署到预发环境。
  7. publish/<x.y.z>的tag提交触发正式构建并部署都正式线。
  8. 正式线发布的版本号严格递增。
  9. 一旦publish/<x.y.z>发布成功则将代码合并到master分支。
  10. 一旦publish/<x.y.z>发布成功则删除对应版本号的daily分支,因为已经无用。
  11. 以后开发新版本基于master来创建新的daily分支。

需要什么

  1. 得有gitlab,这个一般公司都有。
  2. 得配置一下ci,参考使用gitlab ci实现前端资源自动发布 。
  3. 得配置对应的runner,参考使用gitlab ci实现前端资源自动发布。
  4. 得有数据库,因为要存一些状态。

原则

一般来说我写代码遵循的原则有三个:

1. 统一的配置。

一般我写的代码都会有一个config目录,里面是处理各种配置,有自定义的,有处理环境变量的,等等。一来可以通过调整参数改变程序行为,而不是通过改代码,比如部署到哪个域名、部署到哪个路径、daily环境采用哪些校验机制以及检验顺序是什么样的等等。二来这也是解耦的一种手段,一个具体的例子,查一下gitlab runner文档就会发现它不同的版本注入的环境变量名字是不一样的,如果做一个统一处理那么当需要升级gitlab runner的时候就只处理配置就可以了。

2. 模块 + 组装

模块指的是封装通用能力,一般来说模块是JavaScript模块,是一系列的功能函数,接收参数返回处理结果,无状态。一般我只在少数部分维护状态。

组装指的是按照想要实现的结果在一个地方统一的把各无状态的功能模块组装起来。好处是可以明显的看出来程序流程。

3. 数据 + 模式

写代码最忌讳case by case的写,什么时候是个头呢?应该按照模式来写,约定好输入输出,把模式写出来。我曾经写了一个通过User-Agent检测浏览器版本和特性的库,每次想扩展新的浏览器类型非常方便,在数据部分加一条,在单元测试加一下case,跑一遍单测,搞定,核心逻辑部分根本不用变。改核心的逻辑风险大,改数据配置能有多大风险呢。

结束

没写完,还有后续。

可能有一天我们会开源。

推荐文章