本地工作流
- 是本地工具链阶段的前端工程体系所对应的工作模式
- 这个阶段,各个功能模块都是由开发人员在本机环境下执行
- 前端工程体系搭建十分方便
- 开发完成后将其发布到npm仓库,再通过npm工具将其安装到本地
- 便利的安装方式和功能集成在本地的工作模式
二次构建的隐患
- 本地工作流的问题:测试通过之后,要针对生产环境进行二次构建才能部署上线。但是,这属于逆模式。测试的代码应该和生产的代码一摸一样,否则失去了测试的意义。
- 虽然测试环境和生产环境可能仅仅是接口域名的细微差别,但是我们无法保证二次构建的正确
如何解决二次构建的隐患
- 架构层:将因环境不同的代码,单独抽离出来
- 工程化手段:仿真生产环境,也叫测试沙箱
二次构建的根本原因
- 前端静态资源是静态的,不能适应环境
- 即时微小的差异,也要重新构建
代码分离
- 单独写一个适应各种环境的配置文件(manifest.js)
- 根据主站域名区分测试环境和生产环境,再将对应的异步域名暴露出来以全局变量,随后在业务代码中使用这个全局变量
- 这种架构模式构建产出的代码可以在不同的环境运行,避免了二次构建
代码分离的缺陷
- manifest.js 作为一个通用模块,和jquery等第三方库一样,无法保证更新后兼容历史项目
- 不是从工程角度出发的高度可适应方案
测试沙箱
- 搭建一个仿真的生产环境
- 前端只需要一次生产环境的构建,然后测试沙箱,通过后,直接部署上线
- 浏览器插件,可以在浏览器内搭建仿真的前端生产环境
加入测试沙箱后的本地工作流还存在的问题
- 由于是本地构建,开发人员本地环境的差异性可能会导致构建结果不同
- 开发人员忽略版本控制,部署后没有提交
posted on
2022-04-12 15:50
社会优先于个人
阅读(
64)
评论()
收藏
举报