• 博客园logo
  • 会员
  • 众包
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • HarmonyOS
  • Chat2DB
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
社会优先于个人
博客园    首页    新随笔    联系   管理    订阅  订阅
6.1 本地工作流

本地工作流

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

二次构建的隐患

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

如何解决二次构建的隐患

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

二次构建的根本原因

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

代码分离

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

代码分离的缺陷

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

测试沙箱

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

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

  • 由于是本地构建,开发人员本地环境的差异性可能会导致构建结果不同
  • 开发人员忽略版本控制,部署后没有提交
posted on 2022-04-12 15:50  社会优先于个人  阅读(64)  评论(0)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3