阅读 7856

前端自动化发布实战总结

为什么要做

今年4月份,开始自己的第二份工作,习惯了老东家如丝般的发布体验,一下子感觉来到了“原始社会”。 首先这是一篇长文,主要介绍自己在做自动发布这个过程的一些思考。

引用玉伯的Web研发模式演变来说,现在我们处于 - Web1.0时代:

  • 前后端代码耦合
  • java环境对前端过于复杂
  • 缺乏工具和规范,代码难维护
    • 内嵌代码:html内嵌js,jsp内嵌java逻辑
    • 页面级代码,代码叠加:单文件js随意2000行以上
  • 人工手动发布,变更麻烦

遇到这种情况,首先会想到的肯定是前后端分离。但考虑到目前的人员、技术储备情况,直接过渡到基于NodeJS的全栈式开发,阻力大,周期长,很可能会难产。

而我们首要要解决的问题是:

  • 前后端职责清晰
  • 提升开发效率、体验
  • 自动化发布

所以我们暂时先做到前后端物理分离,大致如 - Web2.0时代

  • 代码仓库分离,分开维护
  • 发布部署分离
  • 模板由前端维护,在浏览器渲染,后端只提供基础页面容器(视情况而定)
    • 交互性、非SEO页面:后端负责接口,前端负责展现,通过接口读取数据在浏览器端渲染
    • 需要SEO的页面:相关模板还是放在后端,但是会减少业务逻辑

目标

我们先从开发、发布流程来看我们最终希望的结果是什么,然后再分析如何完成这一目标

开发流程

  • 项目遵循流程:需求评审 -> 视觉评审 -> 接口约定 -> 需求评估 -> TC评审 -> 并行独立开发 -> 联调 -> 测试 -> 发布
  • 开发过程前后端明确任务,独立并行开发

开发流程

发布流程

  • 发布要严格遵守流程,测试审核通过才能上线
  • 整个流程只需简单发布指令,所有的编译构建、同步服务器的事情交给任务去做(后面我们会提到发布任务需要做哪些事情)

发布流程

分离需要做什么

  1. 代码分离 使用git来做代码版本管理,申请新应用维护前端代码
  2. 使用webpack,做模块管理 代码分离后,我们可以使用目前前端主流的框架、工具,搭建友好的开发环境、流程
  3. 分离之后,请求后端接口,联调、debug,都需要设置代理
  4. 自动化发布
  5. 服务器配置 考虑如何部署前端代码

自动化发布

首先聊一下一般发布的流程:

  1. 代码提交
  2. 打包构建
  3. 备份服务器当前文件 - 回滚使用
  4. 将构建结果同步到服务器目录
  5. 合并代码到Master - 保证后续的代码都是最新的

这是一些纯体力活,要保证步骤顺序和正确性,容易出问题,而且没有记录和日志,所以一般做权限控制,发布个普通需求还要找对应的同学发布,变更麻烦

所以发布必须自动化,网上搜前端自动化发布,大多数的结果都是Jenkins + githook ( Jenkins+github 前端自动化部署

其核心原理主要是通过

  1. 提交代码触发webhook push event
  2. Jenkins监听到webhook post请求,执行编写好的脚本构建、同步服务器(主要依赖于脚本)

但是如果我想要查看发布记录、回滚、控制发布流程,看起来Jenkins就帮不上忙了(可能有对应的插件,没深究)

同样的发布脚本,用node也能执行,所以我们打算使用node来写一个发布集成服务来代替Jenkins,它可以做更细致的控制:

  • 提交代码不代表发布,可能只是代码备份,发布指令才代表发布
  • 可以生成发布记录,在发布平台展示,方便查看和回滚
  • 实时反馈发布流程信息
  • 控制发布流程,加入审核、CodeReview,让发布更安全

所以我们的发布自动化主要做三个东西

  • CLI:让熟悉命令行的同学,git push后马上就可以敲命令发布(创建新发布、发布)
  • 发布平台:查看发布记录,发布,审核,查看日志,回滚
  • 集成发布服务:执行发布脚本,同步服务器,备份近期发布文件(快速回滚),反馈发布信息,发布控制

CLI

该CLI是一套标准的前端开发生命周期命令,通过几个子命令去完成前端开发流程的各个任务,包含了:

  • init:初始化项目结构,类似于vue-cli init,不过比较入门简单(因为暂时业务的体量并不需要频繁创建新项目)
  • dev:启动开发调试服务,主要是npm run dev,也不是重点
  • publish:发布项目代码,执行publish后将执行项目仓库中对应开发分支下的代码发布任务。在云端构建后的代码最终会发布到对应的环境(SIT、UAT、生产)。

关于CLI的开发参考 - 如何用Node开发CLI 主要是:commander + inquirer

从此发布就变成了一个命令的事

发布

发布平台

发布平台提供了比CLI更多的功能:

  • 查看发布记录
  • 查看日志
  • 回滚
  • 发布管理、控制

发布平台

集成发布服务

到了重头戏,这里就介绍一些概念

发布流程

日常
预发

线上

为什么在云端构建发布

首先,最终代码部署到服务器肯定都是通过scp等命令来同步文件到服务器,因为权限问题,通过云端统一管控是比较靠谱的。

然后,每个人的机器环境都不一样,有可能在A这构建成功,在B那却构建失败(比如A添加了一个依赖,但没有保存dependencies),所以以统一的环境来编译构建,可以避免因为环境问题引起的构建问题

最后,需要一个地方去统一管理发布记录,避免发布冲突,记录发布日志,方便回滚操作等。

分支管理

每个人都基于Master拉取自定义分支开发,最终通过发布自动同步到Master分支,保证开发时都是基于最新的线上代码,同时发布时做冲突检查,保证发布安全。

发布过程的分支变化如下:

发布过程

发布管理

在整个发布过程,我们的代码要通过日常、预发测试才能最终上线,这个过程是需要占用对应服务器并保持稳定,需要避免出现其他同学发布覆盖的情况,所以我们使用MongoDB来维护发布记录,实现发布控制和流程控制

发布控制 当指定发布环境有一个项目发布时,该环境被占用,其他项目发布会提示有其他项目发布,联系对应的发布同学,双方根据重要性来决定是否退出发布让后来的项目先上

流程控制 为了保证最终上线的代码是正确运行的,整个过程需要测试和Code Review,必须通过测试、审核才能进入下一个环节

发布反馈

发布脚本需要执行上面提到一系列的过程,这需要一个等待的过程,我们需要实时给发布同学提供发布反馈(发布流程、成功与否),并将相关信息保存到日志。所以发布过程通过soket.io建立socket链接,集成发布服务有任何流程变化都会反馈

同步服务器

同步服务器可以使用 scp 或 rsync 命令,关于它们的介绍和不同看这个

这两个命令通过ssh同步,都需要在执行命令后输入密码,所以需要配合expect来实现自动同步

最终整个服务选用了:express + socket.io + mongodb,这里就不赘述了