《重学前端》学习笔记Day132

持续集成：几十个前端一起工作，如何保证工作质量？

持续集成总论：

传统的持续集成主要有以下措施：

• daily build：每日构建，开发者每日提交代码到代码仓库，构建一个可运行的版本。
• build verification test(BVT)：构建验证测试，每日构建版本出来后，运行一组自动化的测试用例，保证基本功能可用。

对于前端来说，有一些现实的区别：
前端按页面自然解耦，大部分页面是单人开发；
前端构建逻辑简单，一般开发阶段都保证构建成功，不需要构建；
前段代码一般用于开发界面，自动化测试成本极高；
前端页面跳转，是基于URL，没有明确的产品边界。
基于以上的分析，传统的持续集成方案放在前端，要么不需要，要么不适用，要么实施成本高。所以我们不能套用传统的持续集成理论，而需要重新思考前端领域的持续集成体系。

持续集成目标

首先是确定前端持续集成的目标，回到持续集成的根本理念，一是及早集成代码形成可测试的版本，二是通过一定的测试来验证提交的代码的有效性。

持续集成的方案

前端持续集成如何完成这两个目标？
前端代码不需要构建，或者说只需要单页面构建，但是页面与页面之间的跳转是用URL构成的，所以我们的可测试版本不可能通过“构建”来获得。
只能通过“发布”来获得一个前端代码的可执行版本，在传统语境中，发布的目标即线上生产环境，这显然不行。所以我们需要一个预览环境，来做一种“虚拟发布”的操作。
为界面编写自动化测试用例成本很高，那么如何代替构建验证版本测试呢？
在上节课程讲到，页面性能可以通过一些自动化工具来分析，还可以通过一些数据采集方案来发现性能问题，对于预览环境前端页面，我们可以采用同样的措施。
除了基于页面结构的分析和数据采集，我们还可以扫描代码。
综上，我认为前端的持续化集成的措施应该是这样的：

• 预览环境，代替每日构建，前端每次（或指定次）提交代码到仓库都同步到预览环境，保证预览环境总是可用。
• 校验规则，代替构建验证测试，通过数据采集（如前面提到的性能数据）和代码扫描，保证提交的代码满足一定的质量要求。

预览环境

规则校验

持续集成的实施

持续集成的结果

此文章为8月Day4学习笔记，内容来源于极客时间《重学前端》，日拱一卒，每天进步一点点💪💪