6.1 本地工作流

本地工作流

• 是本地工具链阶段的前端工程体系所对应的工作模式
• 这个阶段，各个功能模块都是由开发人员在本机环境下执行
• 前端工程体系搭建十分方便
• 开发完成后将其发布到npm仓库，再通过npm工具将其安装到本地
• 便利的安装方式和功能集成在本地的工作模式

二次构建的隐患

• 本地工作流的问题：测试通过之后，要针对生产环境进行二次构建才能部署上线。但是，这属于逆模式。测试的代码应该和生产的代码一摸一样，否则失去了测试的意义。
• 虽然测试环境和生产环境可能仅仅是接口域名的细微差别，但是我们无法保证二次构建的正确

如何解决二次构建的隐患

• 架构层：将因环境不同的代码，单独抽离出来
• 工程化手段：仿真生产环境，也叫测试沙箱

二次构建的根本原因

• 前端静态资源是静态的，不能适应环境
• 即时微小的差异，也要重新构建

代码分离

• 单独写一个适应各种环境的配置文件（manifest.js）
• 根据主站域名区分测试环境和生产环境，再将对应的异步域名暴露出来以全局变量，随后在业务代码中使用这个全局变量
• 这种架构模式构建产出的代码可以在不同的环境运行，避免了二次构建

代码分离的缺陷

• manifest.js 作为一个通用模块，和jquery等第三方库一样，无法保证更新后兼容历史项目
• 不是从工程角度出发的高度可适应方案

测试沙箱

• 搭建一个仿真的生产环境
• 前端只需要一次生产环境的构建，然后测试沙箱，通过后，直接部署上线
• 浏览器插件，可以在浏览器内搭建仿真的前端生产环境

加入测试沙箱后的本地工作流还存在的问题

• 由于是本地构建，开发人员本地环境的差异性可能会导致构建结果不同
• 开发人员忽略版本控制，部署后没有提交