第十三期|关于前端构建，你了解多少

扛把子_商
818 阅读7分钟

文章的开头，我们一起回顾下关于前端上线的历史版本。

构建历史

历史1.0

起初，前后端资源耦合在一起，常常是前端同学本地开发好后，手动将代码发送给后端同学，文件传输甚或是聊天对话框传输。而后后端同学将前端资源存储到后端工程里面，上线时一起部署发布。问题不言而喻，一是手动操作失误性较强，而且不可控。二是前后端协作的频次级高，常常会因一个文字的更改，或者一个标点符号的更改。三是上线回滚方案路径长，难以把控。

历史2.0

此时，前后端资源已经分离，可单独上线。首先前端项目本地打包，生成生产资源，而后将资源通过拷贝/文件传输等操作部署到物理机，来生成测试环境、生产环境。这里的问题在于，一是仍然存在人为操作的失误、无回滚策略，如需回滚，需重新拉取历史代码版本，重新打包部署上线。二是关于前端缓存CDN操作、代码eslint、安全性检查、node_modules安装等等，每次都需要手动操作，如业务范围内有20个项目，则需要做20次重复的工作内容。三对于项目规模较大、体量较大的，还需要考虑多人协作、冲突等问题。

现代

对于以上的历史过程，包括前后端协作、人为失误、重复劳动力等等问题，前端构建应用而生。 下面我们详细来看看前端构建包含哪些内容。

前端构建

概念

构建包括，构建过程（输入源码到生成代码的过程）、构建工具和生态（webpack、rollup、TS）、构建工具的集成（CLI、create-react-app、Vue CLI）、构建服务环境（jenkins、trvalCI）。本篇文章会围绕构建服务环境来进行展开，下面我画了个思维导图，有足够了解的同学可以直接看图来进行了解，当然如果本篇文章给你带来一些思路和对构建的了解，记得点个小心心再走，笔芯～

构建流程

一、代码部署

代码部署作为第一环节，可以做一些本地代码检查。利用GIt Hook，pre-commit/husky来支持本地想要检查的事项。比如eslint规范检查，来强制规范团队内的代码规范。再有如执行单元测试，利用jest/mocha等来做代码提交前的检查测试。当以上都没有问题后，进入在线构建环节。

二、在线构建

当然，上述的eslint，还有单元测试，也可以放到在线构建工具这里来检查，这里没有硬性规定，按照各团队的规模及要求走就可以。 在线构建可以做的检查还有，安全性检查

  1. 安全性检查，如项目内安装了npm上的不安全代码（这里可以累计一些不安全的npm名单，以增加检查速度，同学们有兴趣的可以去了解下著名的flatmap-stream被挖矿事件）。还有关于node_models的无底洞检查，下面是一张比较有意思的图：

意思是宇宙间什么物体质量最大，太阳、中子星还是黑洞，最后获胜的是无底洞的node_moduels依赖，这里推荐一个检查依赖的包shameimaru.js。其他附加检查，还可以拓展一些http协议头检查、非安全域名的检查、以及业务内的必要检查等等。

  1. 性能检查。为优化生产后的打包资源过大问题，我们常常会增加webpack-bundle-analyzer，来观看各个资源的占用情况，统一放到构建工具来做，在开发环境中无需关心和配置。

  2. 依赖的安装。我们通常的npm包安装有三种渠道，npm源、npm淘宝源、私服。当某一渠道网络情况不稳定，构建工具可自动切换源来进行依赖的安装。

  3. 公共资源的注入，可以注入一些项目必备的资源，如埋点、监控、统一登录、公司业务场景内的必备资源等。

  4. 在线构建时，如果每次都进行npm的安装，势必会造成大量的等待时间，这里可以对上一次的node_module做缓存（当然包括版本号的对比等），以此来减少构建部署的等待时间。

  5. 当然还有一些代码压缩、图片压缩、版本生成、CDN的发布等等环节

三、资源存储

  1. OSS存储（Object Storage Service）

  2. Docker镜像仓库

当然，这里的存储方法也可以多种多样，可以结合公司内部的支持程度来结合了解。（这里具体细节不讲，了解下大概思路。）

四、部署分发

部署分发，也就是上线过程，这里分为三种来进行介绍。

  1. 蓝绿部署 蓝绿部署是指，不停止老版本，而对新版本进行升级，测试通过后，将流量切到新版本，之后再对老版本进行升级，流量切换。假如说我们正常需要10台服务器，而蓝绿部署则需要20台来进行交替升级。

  2. 滚动升级 是指将服务中的一部分流量切停，而后进行升级更新，升级后的再切流量进来，以此类推，最终达到所有服务都升级完毕。

  3. 灰度发布 也叫金丝雀发布，是一种平滑过渡的升级发布。AB测就是其中一种。

这里不对发布方法做比较，大家可以根据公司支持情况来使用，具体优缺点可以自行搜索下～

统一在线构建的优点

  1. 各业务方接入成本较低。
  2. 专门的构建环境更加纯净。
  3. 构建的逻辑有针对性的标注化。
  4. 对于代码的安全、性能等检查，后面的拓展性更强。
  5. 线上资源各种历史版本的存储，可以做到上线后的一键回滚。
  6. 基本可以解放每个项目的重复劳动力问题。

构建系统的拓展

  1. 在构建中，可以生成代码内对于框架、组件等级别的使用数据，完全可以用来反馈给公共资源的开发者，进行反哺，促成代码生态的发展。

  2. 构建时的数据采集，包括构建耗时、资源的体积大小等，均可反馈给开发者，并且可以预设阀值，来做严重级别的截断。

  3. 构建时，也可以加入错误监控，包升级等信息。

当然，我认为一切可以减少重复劳动力的工作，都可以按需增加，特色的支持业务发展。

现有方案

  1. 腾讯云开发cloudbase
  2. K8S(也可以看下Rancher)
  3. Travis CI（只支持Github）
  4. GitLab CI/CD

总结

上面讲述了构建系统的发展史，构建流程，以及其中可以做的事项，到最后的环境部署。整体是从思路出发，给大家提供动手的轮廓。

如果你觉得收益了，请点个小心心再走呗～～，当然如果有问题，欢迎留言，相互学习讨论呀～！

关于前端早早聊

前端早早聊大会目标成为用得上、听得懂、抄得走的技术大会，计划 2020 年办 >= 16 期，由前端早早聊与掘金联合举办，前端早早聊大会行程动态、录播视频/PPT/讲稿资料下载请关注 「前端早早聊」 公众号跟进。

你的转发支持，是早早聊走下去的最大动力！

果断加 Scott 微信： codingdreamer 提大会需求哈！ 8 月 29 日/第十四届-前端成长与晋升，报名戳：huodongxing.com/go/tl14

avatar
文章
阅读
粉丝