前端自动化发布实战总结

分离需要做什么

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

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

为什么在云端构建发布

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

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

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

分支管理

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

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

发布管理

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

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

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

发布反馈

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

同步服务器

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

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