前端自动化发布实战总结

前端自动化发布实战总结

为什么要做

今年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

发布平台

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

• 查看发布记录
• 查看日志
• 回滚

• 发布管理、控制

  
  
  发布平台

集成发布服务

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

发布流程

发布日常

发布预发

发布线上

为什么在云端构建发布

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

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

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

分支管理

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

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

分支管理

发布管理

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

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

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

发布反馈

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

同步服务器

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

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

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